Conveying a reason for a call from a user device

ABSTRACT

In one embodiment, the techniques herein are directed to conveying a reason for a call from a user device. For instance, an illustrative method herein may comprise: determining, by a user device, a second device to participate in a call with a user of the user device and a reason for the call; transmitting, from the user device, a message to an intermediate service to inform the intermediate service about the second device, the user, and the reason for the call, wherein the intermediate service conveys the user and the reason for the call to the second device; and receiving, at the user device, the call initiated by the second device, wherein the second device is aware of the user and the reason for the call prior to initiating the call.

RELATED APPLICATION

This application claims priority to U.S. Prov. Appl. No. 63/312,593,filed on Feb. 22, 2022, entitled CONVEYING A REASON FOR A CALL, byMichael Joseph Frendo, et al., the contents of which are incorporatedherein by reference.

TECHNICAL FIELD

The present disclosure relates generally to phone calls such as calls tocontact center interactions and, more particularly, to conveying areason for a call, and even more particularly, to conveying a reason fora call from a user device.

BACKGROUND

A contact center is an entity (centralized or distributed, despite theterm “center”) used for receiving or transmitting a large volume ofenquiries by telephone, video, online audio, or other real-time contactmethodology or live support software. Contact centers may either beoutbound, inbound, or both, where outbound contact centers are typicallyoperated for outgoing contact (e.g., telemarketing, solicitations, debtcollection, market research, fraud alerts, and so on), and inboundcontact centers are typically operated for incoming services (e.g.,incoming product or service support or information enquiries fromconsumers). Banks, for example, may have both inbound and outboundoperations, both accepting incoming user requests (e.g., balanceinformation or transfers), and conversely for reaching out to customerswith outgoing user requests (e.g., fraud alert confirmation, etc.).

Contact center agents may either work in centralized call center or/andin a distributed facilities such as at remote (e.g., home) locationswith workstations that include a computer and display for each agent anda telephone set/headset connected to a telecom switch or to aninbound/outbound call management system, where the voice, txt, and datapathways into the center are linked through a set of new technologiescalled “computer telephony integration”, or multimedia contact centers.These centers can be operated by either an in-house department (of thecompany) or a third-party agency (outside of the company) known as a“contact center outsourcer”.

Through these contact centers, valuable information can be exchangedbetween a company and its customers (or other employees of the samecompany), and customer interactions can be managed generally. One majorproblem faced today, however, is verification of the user at the otherend of the communication. This problem occurs in both directions;namely, a company wants to confirm that they are communicating with theintended customer, and a customer wants to confirm that they arecommunicating with the intended company. Additionally, customers alsowant to know that their information is secure, whether from hackersbreaking into contact center databases, or from unscrupulous contactcenter agents who may simply be keeping notes on personal authenticationinformation, including usernames, passwords, security question answers,and so on.

Moreover, as more and more users operate on mobile devices, theincreasing sophistication of the users results not only in demands forfrictionless user experiences with stringent security to preventimproper use or abuse of their data, but also in a decrease in tolerancefor those operations that do not offer such experiences. Multi-factorauthentication (MFA), though growing in popularity, is an authenticationmethod in which a device or user is granted access to an applicationonly after successfully presenting two or more pieces of evidence (orfactors) to an authentication mechanism: knowledge (something the userand only the user knows), possession (something the user and only theuser has), and inherence (something the user and only the user is).However, MFA can often be a frustrating experience, or can be underminedwith weak authentication correlation (e.g., sending a text message to astolen phone to “confirm” that the user is who he or she says they are).

Furthermore, caller ID is simple to fake. Using various knowntechniques, a hacker can call a bank pretending to be a valid user andcan attempt to transfer funds to another account, or alternatively, ahacker can call a client of a bank pretending to be their bank, and canattempt to obtain and compromise personal information from theunsuspecting called party.

Another major problem faced today is that when a user receives a callthrough conventional systems, this immediately raises numerousquestions:

-   -   Is the call coming from the institute whose name is displayed or        from a hacker spoofing this number?    -   If it is actually a call from a valid institute, why are they        calling me?    -   Is the call urgent? Can we talk at a later, more convenient        time?        Given the gravity of these questions, many institutes including        banks, etc. experience a very low number of answered outbound        calls. Additionally, callers to institutes such as, e.g., banks,        may need to enter multiple questions after they are connected to        an agent which slows the process of addressing the caller's        issues.

SUMMARY

The techniques herein are directed generally to conveying a reason for acall, particularly for a contact center. In particular, according to oneor more embodiments described herein, methods and/or apparatus are shownfor guaranteeing to the called party that the caller ID is correct,conveying the reason for the incoming call, including the urgency of thecall, and providing the user with an easy mechanism for rescheduling thecall for a different time.

Specifically, in one embodiment, the techniques herein are directed toconveying a reason for a call to a user device. For instance, anillustrative method herein may comprise: identifying, by an initiatingdevice of an organization, a user and a reason for a call to a recipientdevice of the user, the user device having an inbound phone number;informing, by the initiating device, an intermediate service about thecall to the recipient device and the reason for the call, wherein theintermediate service coordinates with an application on the recipientdevice to inform the recipient device of the call, an outbound phonenumber of the call, a name of the organization, and the reason for thecall; and calling, from the initiating device and using the outboundphone number, the recipient device at the inbound phone number, whereinthe application on the recipient device has configured a calleridentification process on the recipient device to display, in responseto receiving the call from the outbound phone number, the name of theorganization and the reason for the call.

In another embodiment, the techniques herein are directed tocoordinating conveying a reason for a call to a user device. Forinstance, an illustrative method herein may comprise: receiving, at anintermediate service device, information about a call to be made from aninitiating device to a recipient device of a user, the informationincluding a reason for the call; coordinating, by the intermediateservice device, with an application on the recipient device to informthe recipient device of the call, an outbound phone number of the call,a name of an organization of the initiating device, and the reason forthe call, wherein the application on the recipient device configures acaller identification process on the recipient device to display, inresponse to receiving a subsequent call from the outbound phone number,the name of the organization and the reason for the call; andconfirming, by the intermediate service device with the initiatingdevice, that the recipient device has been informed of the call,wherein, in response to the initiating device calling the recipientdevice using the outbound phone number, the caller identificationprocess on the recipient device displays the name of the organizationand the reason for the call.

In another embodiment, the techniques herein are directed to receiving areason for a call at a user device. For instance, an illustrative methodherein may comprise: receiving, at an application on a recipient deviceof a user, information about a call to be made from an initiatingdevice, the information having an outbound phone number of the call, aname of an organization of the initiating device, and a reason for thecall; and configuring, by the application, a caller identificationprocess on the recipient device to display, in response to receiving asubsequent call from the outbound phone number, the name of theorganization and the reason for the call; wherein, in response to theinitiating device calling the recipient device using the outbound phonenumber, the caller identification process on the recipient devicedisplays the name of the organization and the reason for the call.

In another embodiment, the techniques herein are directed to conveying areason for a call from a user device. For instance, an illustrativemethod herein may comprise: determining, by a user device, a seconddevice to participate in a call with a user of the user device and areason for the call; transmitting, from the user device, a message to anintermediate service to inform the intermediate service about the seconddevice, the user, and the reason for the call, wherein the intermediateservice conveys the user and the reason for the call to the seconddevice; and receiving, at the user device, the call initiated by thesecond device, wherein the second device is aware of the user and thereason for the call prior to initiating the call.

In another embodiment, the techniques herein are directed tocoordinating conveying a reason for a call from a user device. Forinstance, an illustrative method herein may comprise: receiving, at anintermediate service device, a message from a user device, the messageinformative of a second device to participate in a call with a user ofthe user device and a reason for the call; and conveying, from theintermediate service device, the user device, the user, and the reasonfor the call to the second device, wherein the second device initiatesthe call to the user device and is aware of the user and the reason forthe call prior to initiating the call.

In another embodiment, the techniques herein are directed to receiving areason for a call from a user device. For instance, an illustrativemethod herein may comprise: receiving, by a particular device, anindication from an intermediate service that a user device requestedthat the particular device participate in a call with a user of the userdevice, the indication also including a reason for the call;determining, by the particular device, when the particular device isable to initiate the call; and initiating, by the particular device andin response to being able to initiate the call, the call to the userdevice, wherein the particular device is aware of the user and thereason for the call prior to initiating the call.

While various embodiments have been discussed in the summary above, itshould be appreciated that not necessarily all embodiments include thesame features and some of the features described above are not necessaryfor all embodiments. Numerous additional features, embodiments, andbenefits of various embodiments are discussed in the detaileddescription which follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein may be better understood by referring to thefollowing description in conjunction with the accompanying drawings inwhich like reference numerals indicate identically or functionallysimilar elements, of which:

FIG. 1 illustrates an example simplified computer network;

FIG. 2 illustrates an example of a computing device;

FIG. 3 illustrates an example of verified communication between twoendpoints according to one or more embodiments herein;

FIG. 4 illustrates an example of a “zero-knowledge enablement network”framework according to one or more embodiments herein;

FIG. 5 illustrates an example basic architecture and example flow foruser onboarding according to one or more embodiments herein;

FIG. 6 illustrates an example of verifying a user connecting to acontact center, whether inbound or outbound, according to one or moreembodiments herein;

FIG. 7 illustrates an example architecture for user verification,particularly an inbound scenario where an access and verificationservices (AVS) user (a user with an AVS app) calls from the AVS appitself according to one or more embodiments herein;

FIG. 8 illustrates an example flowchart detailing a procedure from thepoint of view of an access control gateway (ACG) in FIG. 7 aboveaccording to one or more embodiments herein;

FIG. 9 illustrates an example architecture for user verification, nowwhere an AVS user, with the AVS app, calls the contact center directlyfrom a mobile phone according to one or more embodiments herein;

FIG. 10 illustrates an example flowchart detailing a procedure for FIG.9 above according to one or more embodiments herein;

FIG. 11 illustrates an example architectural flow for a non-verifieduser according to one or more embodiments herein;

FIG. 12 illustrates an example flowchart detailing a procedure for FIG.11 above according to one or more embodiments herein;

FIG. 13 illustrates an example architecture view of the contact centermaking an outbound call to a user's phone number (or other contactingidentification, such as for VoIP, video calls, etc.) according to one ormore embodiments herein;

FIG. 14 illustrates an example flowchart detailing the outboundprocedure described above in FIG. 13 according to one or moreembodiments herein;

FIGS. 15A-15I illustrate an example walkthrough discussion of providingaccess control and user verification for a contact center according toone or more embodiments herein;

FIGS. 16A-16D illustrate an example for pushing an outbound request forcommunication (i.e., the contact center pushes a notification to theuser) according to one or more embodiments herein;

FIGS. 17A-17B illustrate an example where the user ignores an initialnotification according to one or more embodiments herein;

FIGS. 18A-18D illustrate an example of an outbound call being requestedfrom the user according to one or more embodiments herein;

FIG. 19 illustrates an example for when a user calls the enterprise'sphone number directly according to one or more embodiments herein;

FIGS. 20A-20B illustrate an example where a user has opened their AVSapp, but has not yet logged in (i.e., an inbound call pre-login)according to one or more embodiments herein;

FIGS. 21A-21B illustrate an example where the user has opened their appand has logged in (i.e., an inbound call post login) according to one ormore embodiments herein;

FIG. 22 illustrates an example “zero knowledge” request and verificationaccording to one or more embodiments herein;

FIG. 23 illustrates an example of verification token passing accordingto one or more embodiments herein;

FIG. 24 illustrates an example simplified procedure for providing accesscontrol and identity verification for communications between aninitiating device and a recipient device in accordance with one or moreembodiments described herein;

FIG. 25 illustrates an example architecture for conveying a reason foran outbound call in accordance with one or more embodiments describedherein;

FIG. 26 illustrates an example architecture for conveying a reason foran inbound call in accordance with one or more embodiments describedherein;

FIG. 27 illustrates an example simplified procedure for conveying areason for a call to a user device in accordance with one or moreembodiments described herein;

FIG. 28 illustrates an example simplified procedure for coordinatingconveying a reason for a call to a user device in accordance with one ormore embodiments described herein;

FIG. 29 illustrates an example simplified procedure for receiving areason for a call at a user device in accordance with one or moreembodiments described herein;

FIG. 30 illustrates an example simplified procedure for conveying areason for a call from a user device in accordance with one or moreembodiments described herein;

FIG. 31 illustrates an example simplified procedure for coordinatingconveying a reason for a call from a user device in accordance with oneor more embodiments described herein; and

FIG. 32 illustrates an example simplified procedure for receiving areason for a call from a user device in accordance with one or moreembodiments described herein.

DESCRIPTION OF EXAMPLE EMBODIMENTS

A computer network is a distributed collection of nodes (e.g.,transmitters, receivers, transceivers, etc.) interconnected bycommunication links and segments for transporting signals or databetween the nodes, such as personal computers, workstations, mobiledevices, servers, routers, or other devices. Many types of computernetworks are available, including, but not limited to, local areanetworks (LANs), wide area networks (WANs), cellular networks, broadbandnetworks, infrastructure or backhaul networks, public switched telephonenetworks (PSTNs), and many others.

FIG. 1 illustrates an example, and simplified, computer network 100. Asshown, computer network 100 may contain various devices communicatingover links 110 and an internetwork 115, such as end devices 120, servers130, databases 140 (which may be part of servers 130 or in communicationwith and under the control of servers 130), and other devices as will beappreciated by those skilled in the art. Data transmissions 150 (e.g.,packets, frames, messages, transmission signals, etc.) may be exchangedamong the nodes/devices of the computer network 100 using predefinedcommunication protocols where appropriate over links 110. In thiscontext, a protocol consists of a set of rules defining how the nodesinteract and exchange information with each other.

Notably, the computer network 100 may comprise various individualnetworks intercommunicating with each other, such as LANs, WANs,cellular/LTE networks, PSTN, and so on, and may include any number ofwired or wireless links between the devices, accordingly. Note also thatwhile links 110 are shown generically interconnecting with theinternetwork 115, any number of intermediate devices (e.g., routers,switches, firewalls, etc.) may actually make up the composition of thenetwork 100 and internetwork 115, and the view shown herein is merely asimplified illustration.

End devices 120 may comprise different types of devices, such as, e.g.,personal computers, desktop computers, laptop computers, mobile devices,tablets, smartphones, wearable electronic devices (e.g., smart watches),smart televisions, set-top devices for televisions, workstations, smartvehicles, terminals, kiosks, automated teller machines (ATMs),applications running on such devices, and so on, often interfacing withhuman users, though not necessarily. For instance, end devices 120 mayalso comprise drones, automated vehicles, artificial intelligence“beings” or robots, internet of things (IoT) devices, and so on.

Servers 130 and/or databases 140 may comprise singular servers and/ordatabases, server and/or database farms, cloud-based server and/ordatabase services, network attached storage (SAN), and any other type orconfiguration of computing devices that provides computing and/orstorage services as will be appreciated by those skilled in the art.Servers 130 and/or databases 140 may be centralized (i.e., processingand/or storage occurring on a single device or within a single locationof devices) or distributed/decentralized (i.e., processing and/orstorage occurring across multiple devices or across a plurality oflocations). Notably, for example, servers 130 and/or databases 140 maybe deployed on the premises of an enterprise or may be cloud-based.

FIG. 2 is a simplified schematic block diagram of an example computingdevice 200 that may be used with one or more embodiments describedherein (e.g., end device 120, sever 130, database 140, etc.).Illustratively, device 200 may generally include one or morecommunication interfaces 210, one or more processors 220, and a memory240 interconnected by a system bus 250 or other dedicated circuitry, andis powered by a power supply system 260. Additionally, the device 200,where required, may comprise one or more user interfaces 230 configuredto solicit and receive user input (input/output or “I/O” components,such as displays, keyboards, touchscreens, biometrics, and so on).

The communication interfaces 210 include the mechanical, electrical, andsignaling circuitry for communicating data over wired and/or wirelesslinks of a communication network.

The memory 240 includes a plurality of storage locations that areaddressable by the processor(s) 220 for storing software programs anddata structures associated with the embodiments described herein. Theprocessor(s) 220 may comprise necessary elements or logic adapted toexecute the software programs and manipulate the data structures 245. Anoperating system 242, portions of which are typically resident in memory240 and executed by the processor(s) 220, functionally organizes thedevice by, among other things, invoking operations in support ofsoftware processors and/or services executing on the device.Illustratively, these software processes and/or services may include oneor more functional processes 246 (e.g., specific to functionality of thedevice), and an example “access and verification” process 248 that isconfigured to perform the operations described herein.

It will be apparent to those skilled in the art that other processor andmemory types, including various computer-readable media, may be used tostore and execute program instructions pertaining to the techniquesdescribed herein. Also, while the description illustrates variousprocesses, it is expressly contemplated that various processes may beembodied as modules configured to operate in accordance with thetechniques herein (e.g., according to the functionality of a similarprocess). Further, while processes may be shown and/or describedseparately, those skilled in the art will appreciate that processes maybe routines or modules within other processes.

—Access Control and Identity Verification—

As noted above, one major problem faced today is verification of usersat the other end of a communication, in both directions. That is, acompany often wants to confirm that they are communicating with anintended customer, while a customer often wants to confirm that they arecommunicating with the intended company. The same could be true for anytwo users or end-points at either end of a communication.

For example, imagine that a bank initiates an outbound call to a user inorder to verify suspicious activity on the user's account. When theperson answers the phone, the bank may wish to verify that the personanswering is actually the user/owner of the account. Since simply askingthe question if they are the owner of the account is clearlyinsufficient to verify identity, the bank can either ask securityquestions or may send a multi-factor authentication (MFA) request forthe user's account. In the former case, people close to the accountowner, such as family or friends who may have answered the phone, mayknow many of the answers, such as first car, mother's maiden name,street the user grew up on, etc. Also, if the MFA verification uses thephone, such as a text message, email, etc., then all MFA accomplishes isconfirming that the answerer has the user's phone, and not necessarilythat they are, in fact, the user.

As another example, assume that the user is actually answering the callfrom the bank. How, now, can the user confirm that it is actually thebank (or government, or doctor, or school, and so on) that is calling?Today, most users rely on the company first providing some informationthat at least indicates that they know something about the user, butmany users still fall victim to phishing attempts where the caller hassomehow obtained portions of identifying information (e.g., user's name,phone number, address, last four digits of a social security number,etc.), or the users may simply answer verification questions (passwords,pins, security questions, account numbers, etc.) without evenquestioning whether they are answering the actual company or someoneelse looking for fooled users to supply the information.

For example, one potential attack on obtaining source data from one oreven a plethora of source devices is a phishing or spear-phishingattempt. Generally, phishing is the fraudulent practice of purporting tobe from a reputable company in order to induce individuals to revealpersonal information, such as passwords and credit card numbers, whilespear-phishing is the research-based practice of pretending to be aknown or trusted sender in order to induce specifically targetedindividuals to reveal confidential information or transfer funds.Through such a practice, it is possible that a source device (or theuser at the source device) could be fooled into authorizing the sharingof sensitive source data with an otherwise unauthorized recipientdevice.

Through the increased proliferation of digital identities, not only aremore than 1-in-10 new account creations fraudulent, but the other9-in-10 are subject to 100% growth year-over-year in attacks to accesssensitive information in a user's account, whether through accounttakeover or through breaking into and accessing a less-than-securedatabase.

Information privacy and security are thus particularly important toconsumers and computer technology. With the proliferation of hackingincidents against user information, attack vulnerability has beenaddressed in many ways to prevent or at least detect unsanctioned accessto data and user information. Still, to this day, such efforts have beenunable to keep up with the dedication of ill-willed individuals toovercome the many layers of security, the authorized access management,and the overall ever-changing data security landscape set forth by theadministrators tasked with protecting the stored and communicated data.As mentioned further above, customers want to know that theirinformation is secure, whether from hackers breaking into contact centerdatabases, or from unscrupulous contact center agents, whether at alegitimate contact center or pretending to be part of a legitimatecompany, who may be stealing personal authentication information,including usernames, passwords, security question answers, and so on.

Further breakdowns of trust and verification can be problematic as wellfor communications generally, such as where a person may pretend to becalling from a bank or other enterprise when calling a user. Forexample, by convincing the called party that the caller is the bank, thecalled party may be tricked into disclosing private information to anunverified caller who is merely claiming to be (and is not) the actualbank/enterprise. Even more so, there is sadly a risk that anunscrupulous contact center agent may use (or sell to another immoralperson on a black market, e.g., the “dark net”) the personal informationof a client, such as by merely copying or remember the privateinformation (e.g., passwords, pins, mother's maiden name, etc.). Thesecrooks could then use the stolen information in a fraudulent call to thebank/enterprise and convincingly pretend to be the lawful entity.

Accordingly, to address the needs of today's sophisticated users andcompanies, and to prevent infiltration by today's sophisticated hackers,the techniques herein are directed to frictionless user experience andstringent security to prevent improper use or abuse of privateinformation, and also provide intelligent end-user verification withoutsacrificing the security of the private information. That is, thetechniques herein provide access control, assurance that a user iscalled by a valid enterprise rather by a hacker spoofing the ID of theenterprise, as well as user verification for communications, such as forcontact centers. In general, the techniques herein address theverification of the identity of any entity at either end of acommunication (i.e., an identity associated with either the initiatingdevice or a receiving device), where the entity may be a person (i.e.,user of a device), the device itself, or an enterprise (e.g., a company,bank, government facility, etc.) and any of its authorized agents.

With reference to FIG. 3 , verified communication 300 includescommunications 310 (voice calls, text, video calls, etc.) between twoendpoints (over a “communication channel”), illustratively mobiledevices 315 and an enterprise, e.g., a contact center 320 (e.g., throughan automatic or automated call distributor, “ACD” 325). Through servicesoffered by the techniques herein, referred to generally as “access andverification services” (AVS) (as well as the corresponding AVSapplication/clients/servers that are configured to participate in suchservices, as described herein, such as AVS server 335 as shown in FIG. 3), a digital identity verification service may utilize “out of band”data network signaling 330 (over a “verification channel”) to ensure thecommunicating parties (caller and receiver) are who they say they are.Note that as used herein, the “out of band” verification channel impliesthat the verification occurs outside of the communication channel. Inother words, where the “communication channel” is whichever transmissionmedium is providing the communication between the two end devices (e.g.,over PSTN, the Internet, etc.), the “verification channel” is a separatedata communication channel (e.g., still possibly over the Internet orother secure transmission network) that provides the verification ofidentities as described herein (e.g., communications between the enddevices and the corresponding AVS application/clients/servers that areconfigured to facilitate identity verification). Note that in certainexample embodiments, the verification channel and communication channelmay traverse through the same paths (e.g., both over the internet, butstill separate in that the verification does not occur vocally over thevoice call or other communication medium, such that the verifier neednot hear/see any authentication factors of the entity to be verified).In accordance with yet another example implementation the verificationprocess takes place over an in-band communication channel.

The strong authentication process offered by the verified digitalidentity techniques herein:

-   -   is frictionless (e.g., knowledge-based authentication (KBA) is        eliminated);    -   has proof of mobile device ownership;    -   has proof of ownership of credential:        -   (e.g., biometric multi-factor, such as fingerprint,            4-Finger, palm, eye, face, etc.);        -   (e.g., behavioral and continuous verification (e.g.,            location, motion, app usage, etc.);    -   has authentications that include and in some example embodiments        enforce a “risk factor rating”;    -   verifies the identity of both an end-user and the calling        institute (e.g., a bank);    -   does not require participation by contact center agents in the        authentication process, and as such they a) do not see or hear        any credentials of the caller (e.g., only knowing that the        caller has been verified and authenticated by the application),        and b) do not spend time being involved in authentication, thus        enhancing the overall productivity of the contact center; and    -   does not require a contact center agent to disclose any        information to a called party (an outbound call), but rather the        called party may only receive a verification notification that        the caller (e.g., the bank/enterprise) is who the calling party        claims to be.

Additionally, according to the techniques described herein, for eachsecure contact center call setup, the system:

-   -   provides company-verified or AVS-verified identity;    -   eliminates dependence on Caller ID and voice analysis;    -   eliminates interactive voice response (IVR) pin reset attacks;    -   eliminates call setup impersonation;    -   eliminates insider attacks—(personally identifying information        (PII) data minimized);    -   reduces customer friction with highly personalized call        treatment and without requiring re-verification; and    -   increases efficiency of a call center by automating the process        of end user verification and eliminating the need of contact        center agents to participate in the authentication process.    -   increases efficiency of a call center by facilitating means for        the calling party (either the institute or the customer) to        convey the reason for the call and or the urgency of the        contact. This improves the service the user gets from the        institute by handling contacts with the right priority and        ensuring that called party is better informed to handle incoming        calls.

In accordance with a specific implementation, rather than using the newcommunication channel to convey a reason for the call, the calling partymay utilize the secured communication channel to convey a command or aninstruction to the called party.

With regard to PII, identity information, such as the Know Your Customer(KYC) data, is also critical for systems that operate, in at least somecapacity, based on the provable identity of a user. In particular,source devices can be spoofed (i.e., the source device identifies itselfas legitimate, when it is in fact only pretending to be the identifiedsource device), or users themselves can provide false identification(e.g., for money laundering, spear-phishing, or other criminal orgenerally malicious intent). For example, while online gaming is onearea where proving a gamer's real-life identity is likely not criticalto the operation of the game, banking, on the other hand, isgovernmentally regulated to require customer identification to beassociated with bank accounts. That is, though banks themselves may notneed to know more than an account number in order to perform atransaction, name matching against lists of known parties (such as a“politically exposed person” or PEP), determination of the customer'srisk in terms of propensity to commit money laundering, terroristfinance, or identity theft, and a plethora of other reasons have createdthe requirement by many governments that financial institutions need toverify the identity of individuals wishing to conduct financialtransactions with them (e.g., Bank Secrecy Act/Anti-money launderingcompliance programs). Specifically, strict background checks may benecessary and information must be shared from many different financialinstitutions in order to help combat money laundering due to oftencomplex ownership and company structures. In addition to banks, too,customers of various businesses, such as retail merchants, are oftenrequired to present an identification to complete a transaction or tosign up for a service. For instance, a merchant may require customeridentification for various types of purchases (e.g., alcohol, lottery,or tobacco purchases) or when certain types of payments (e.g., checks,credit cards) are presented to pay for transactions. Other reasons foridentity verification include “sock puppetry”, underage signups,spamming, and illegal activities like harassment, scams, and moneylaundering through social media sites.

FIG. 4 illustrates an example of a “zero-knowledge enablement network”framework 400 that may be used for the Identity Network Services systemdescribed herein (e.g., AVS). Notably, the left “leg” 410 of theframework is technology that eliminates liability resulting from storingcustomer PII. Such a “zero-knowledge” data management network, forexample one as described in commonly owned, co-pending, U.S. patentapplication Ser. No. 16/703,846, filed on Dec. 4, 2019, entitled STORINGINFORMATION WITHIN A ZERO-KNOWLEDGE DATA MANAGEMENT NETWORK, byShockley, et al., now published as US-2020-0228506-A1 on Jul. 16, 2020,the contents of which being incorporated herein by reference in itsentirety, allows users to share verifiable proof of data and/or alimitless list of details about themselves (identify information), andbusinesses are able to request, consume, and act on the data, providinga hyper-personalized experience—all without a data storage server orthose businesses ever seeing or having access to the raw sensitiveinformation. That is, the embodiments herein may utilize a decentralizednetwork for trust, identity, privacy, and personalization that reinventssecure data storage and digital identities, where server-stored data isviewable only by intended recipients (which may even be selected afterstorage of the data). Perhaps more importantly, the techniques hereinallow for devices without access to the data to trust the contents ofthe data (e.g., without even being able to decrypt and access/read thedata), guaranteeing that a user's identity is what he/she claims it tobe. That is, the zero-knowledge data management system herein canstrategically employ the use of an attestation service (e.g., anidentity verification service) or other identity verification service(e.g., biometrics such as facial recognition, iris recognition,fingerprinting, voice recognition, etc.), with controlled and limitedaccess to the data (i.e., if desired, no access to the data itself, butinstead only access to the fact that the data (to which one does nothave access) is verified to be correct).

The “right leg” 420 of the framework in FIG. 4 addresses verificationfor each user at either end of a communication, such as users connectingto an enterprise e.g., via a contact center or other user-basedapplication. For instance, using an attestation service or otheridentify verification service through a common architecture (or througha secure interface), the techniques herein may establish a frictionlessuser experience for users that is above and beyond typical multi-factorauthentication, in terms of security (ensuring identity), privacy(protecting identity), and frictionless user experience (ease offunctionality).

According to the techniques herein, users are able to share verifiableproof of data, and a limitless list of details about themselves.Enterprises, on the other hand, are able to request, consume, and act onthe data, and can provide a personalized experience without compromisingprivacy or security. Also, enterprises are able to prove that they arethe enterprise they claim to be, without disclosing any confidentialinformation to the called (or calling) party. In addition, the methodsherein (described further below) provide a mechanism for conveying areason for a call, or for establishing a contact, such as a callerconveying to a called party the reason for the call and the urgencyassociated with the call (or otherwise contact request). In accordancewith another specific implementation, the secured communication channelis used for conveying instructions or otherwise commands to the calledparty. Notably, according to the techniques herein, this allaccomplished without:

-   -   a data storage server having access to the raw sensitive        information;    -   those businesses ever seeing or having access to the raw        sensitive information;    -   sacrificing how the businesses interact, and transact with the        customers; and    -   sacrificing compliance with all business legal obligations.

The techniques herein thus enable enterprises to verify users of mobileand VoIP devices to their contact centers without storing sensitiveinformation on a central server or exposing sensitive information tocontact center agents. In this manner, the techniques herein:

-   -   reduce fraud and defend against account take over;    -   reduce average call handling time;    -   reduce authentication expense;    -   improve customer experience;    -   protect users from fraud resulting from identity theft such as        account take over;    -   protect users from agent and contact center access to sensitive        user information; and    -   assure that the calling party is what it claims to be (by caller        ID and/or timing), without the need for the calling or called        party to divulge sensitive information of the called user or the        caller (notably increasing the rate of successful call        completion for outbound calls, since one of the issues        enterprises, e.g., banks, face is that when they call clients,        the clients assume that it is a fraud and they do not answer,        resulting in a low rate of successful calls).    -   provide a mechanism for the called party to convey to the called        party the reason for the call.    -   provide a mechanism for the called party to convey to the called        party the urgency of the call.    -   allow the called party to issue instructions and or commands to        the called party; commands that in some specific implementations        may be executed automatically by the called party.

The techniques herein are specifically tailored to avoid sacrificing howcompanies market, interact, and transact with their customers, or howthey generate reports for third-parties (e.g., government regulatoryagencies). For instance, as described below, each user connecting theenterprise or the contact center may be categorized as “validated” or“not validated” (or “verified” versus “unverified”). For those that arenot validated, each company, based on their fraud tolerance thresholds,will have their own policy/practice for how to handle those unvalidatedusers. In other words, as described below, the techniques herein reducefraud by providing identity assurance, and reduce authentication expenseby automatically sorting calls from verified/non-verified connectingusers without burdening the validated connecting users. This cantranslate into a significant savings for the authentication process.Similarly, by enabling the calling party to convey the reason for thecall and its urgency, the called party may be better equipped to respondproperly to the incoming contact request.

FIG. 5 illustrates an example basic architecture 500 and example flowfor user onboarding. For instance, the illustrative primary componentsof the architecture are the “AVS server” 510 (implementing or at leastcoordinating/facilitating the techniques herein), a mobile device 520operating an “AVS client” or application/app 525, and an enterprise 530(e.g., bank), which may be embodied as a local, remote, or distributedcontact center. Additionally, an attestation agency 540 may be used toattest to (verify) the identity of the user 505. In certain embodiments,a compliance service 550 (e.g., the government) may also be connected tothe AVS server and the enterprise in order to request and receivereports about the users, as will be understood by those skilled in theart. Note that for certain embodiments herein, the communicationsbetween the devices in FIG. 5 may be securely managed (transmitted andstored) in accordance with a zero-knowledge data management network asmentioned above. That is, the architecture 500 of FIG. 5 may be used inconjunction with the zero-knowledge data management technique describedin FIG. 4 above, serving as a foundation for a infrastructure of boththe zero-knowledge data management system and the access control andidentity verification system described herein.

According to one specific embodiment of user onboarding andauthentication, a third-party (e.g., the AVS server) can obtainattestation from an attestation service by: storing PII information on athird-party server, wherein the third-party server and an attestationservice cannot read the stored information; storing, on the third-partyserver, a re-encryption key that converts the stored information to aformat readable to only the attestation service; requesting, by thethird-party server from the attestation service, attestation of whetherthe stored information is correct, wherein requesting comprises applyingthe re-encryption key to the stored information and sending the storedinformation, in the format readable to only the attestation service, tothe attestation service; receiving, by the third-party server from theattestation service, an indication as to whether the stored information,which cannot be read by the third-party server, is attested as correctby the attestation service; and providing, from the third-party server,the indication as to whether the stored information is attested ascorrect by the attestation service to an interested device (e.g., theenterprise/bank), without the third-party server knowing theinformation.

Specifically, this type of “zero-knowledge attestation” according to oneor more specific embodiments herein, begins with attestationagency/server being configured as a verification service that comprisesone or both of automated attestation or manually assisted attestationtechniques, as generally understood by those skilled in the art. Forexample, a typical identity verification service, in particular, ensuresthat users or customers provide information that is associated with theidentity of a real person, such as by verifying the authenticity ofphysical identity documents such as a driver's license or passport(“documentary verification”), and/or by verify identity informationagainst authoritative sources such as a credit bureau or government data(“non-documentary verification”). Manually-assisted techniques, whichmay be performed also through artificial intelligence, may includeidentity verification through webcams (e.g., holding up a driver'slicense next to a user's face to confirm the visual comparison and thedata on the license). Identity “scoring” (e.g., likelihood that a useris who they say they are) may also be used and shared as a result, e.g.,rather than (or in addition to) a simple yes/no or verified/not result.To attest to data integrity, on the other hand, various methods oftrusted computing and remote attestation may be used, allowing a programat the source device to authenticate itself (e.g., the software/versionrunning at the source device) or the data (e.g., computed hashes,configuration data, revision tracking, and other data/meta-data-basedinformation). Completeness of the records/data may also be attested to,such as confirmations that all requested data fields have been filled inwith legitimate answers, even if the accuracy of the answers themselvesare not specifically attested to in certain configurations. Note thatmany different techniques may be used for identity and data integrityattestation, and that the specific techniques shown herein are merelyexamples for a better understanding of the role and responsibilities ofattestation server/agency.

With reference still to FIG. 5 , a communication exchange between thedevices of the attestation service environment is based on anattestation request from the AVS server. Generally, any device withinthe system in FIG. 5 can initiate the attestation request, such as theAVS/storage server, the mobile device, or the enterprise/bank as averifying recipient device which may receive a signed certificate, aconfirmation message, etc., without ever seeing the actualinformation/PII used for attestation.

As an example, a user 505 may enter his/her identity information (e.g.,KYC information) as “source data” (PII data) 581 at the source device520 (e.g., through the AVS app/client 525, which may bedownloaded/obtained (582, as shown) from the enterprise 530 (e.g.,branded), or from the AVS Server 510 (e.g., general)). The source devicemay then open an account (e.g., a bank account) through request 583, andsince the source data is intended to be kept in secret, the sourcedevice or the controller device (enterprise 530) may inform the storageserver 510 that a new user is trying to open an account (report 584),and that an attestation to the identity of the user is needed (i.e., thesource/PII data), thus “report 584” is also an “attestation request584”. Notably, collection of the source data may be generalized (e.g.,the source device collects the data to share generally with otherdevices as requested), or else the collection may be specificallydirected by other devices, such as the attestation server, thecontroller device, or any other verifying recipient device. That is, thesource device may receive instructions from any of these devices tocollect the source data, either generally or in response specifically toan attestation request.

The attestation server 540 shares its public key (A PubK) 585, either tothe source device 520 directly or else to the storage server 510 who canthen share it with the source device. Alternatively, the attestationserver public key may be shared with the source device by any othermethod, including by being publicly known. Note that the source devicemay already have the attestation server's public key prior to theattestation request, or else may receive it in response to theattestation request (e.g., the storage server connects with theattestation server and obtains the attestation server's publicencryption key, to then share it with the source device).

At this point, in this specific embodiment, the storage server 510 mayeither already have the source-encrypted source data (PII encrypted bythe user's public key, U PubK) 586, or else the source device mayencrypt the source data and provide the storage server with thesource-encrypted source data 586. Here, the source device 520, inresponse to the attestation request (and in certain embodiments, thusreceiving the attestation public key) establishes anattestation-server-based rekeying key 587 through an encryptingcombination of the source decryption key (e.g., a private key, U PriK)of the source device and the attestation server public key (A PubK).Accordingly, by sending the attestation-server-based rekeying key 587 tothe storage server 510, and in response to the attestation request 584received at the storage server (i.e., a request to share the source/PIIdata with the attestation server), the AVS/storage server re-encrypts(e.g., is caused to re-encrypt) the source-encrypted source data 586with the attestation-server-based rekeying key 587, where there-encrypting results in the source/PII data being encrypted with theattestation server public key (attestation-server-based encrypted sourcedata 589). Note still that the AVS/storage server is unable to decryptthe source data encrypted with the attestation server public key (i.e.,attestation-server-based encrypted source data 589).

The AVS/storage server 510 may then send the attestation-server-basedencrypted source data 589 to the attestation server 540 in response tothe attestation request. Notably, the specific attestation request forsource data may be associated with a trackable identifier (ID) in orderto coordinate the attestation to the source data (e.g., a hash functionof the data). That is, the ID pairs the request (and also a signedcertificate, described below) with the source data (and thussource-encrypted source data).

Once the attestation server 540 receives the source data encrypted withthe attestation server public key (attestation-server-based encryptedsource data 589) from the storage server 510, then the attestationserver applies its own private key to obtain and process the user'sidentity information from the previously encrypted source data (i.e.,decrypting the attestation-server-based encrypted source data using anattestation server private key of the attestation server).

The attestation server may now view, verify, and attest to the decryptedsource data (e.g., to the personally identifying information (PII), orelse to the data integrity in other examples mentioned herein), usingvarious attestation techniques. For example, PII may be attested tobased solely on the source data (e.g., documentary verification) or elseon greater information (e.g., non-documentary verification). Forexample, a communication may be established between the source deviceand the attestation server, where the attestation server is configuredto attest to the PII based on the source data and user interaction viathe established communication (e.g., webcam verification, real-timequestion answering, etc.). Any suitable attestation technique may beused herein, and those mentioned above are merely example embodimentsfor illustration.

Assuming the data is verified by the attestation server 540 (e.g.,manually, autonomously, and/or autonomously with manual assistance),then the attestation server creates a signed certificate (KYC Y/NVerified) 590 signifying (acknowledging) the attestation to the sourcedata (or non-attestation). The attestation contents of the certificatemay be anything from a simple “verified” indication, an attestationscore, a report of what is being attested to (e.g., “this certifies thatuser ID #12345 has acceptably provided their identity on this date”),and so on. In particular, according to the techniques herein, theattestation server creates a signed certificate (based on attesting tothe source data) that would allow a verifying recipient device toconfirm that the source data has been attested to by the attestationserver based only on the signed certificate (i.e., withoutaccessing/decrypting the source-encrypted source data). In oneembodiment, the verification may be associated with a particularidentification number tying it to the original request (e.g., an “AVS #&Verified” message 591), either by the attestation server 590 or appendedby the AVS server 510.

In one embodiment, similar to digital signature techniques, theattestation server 540 signs its verification message (signing thesigned certificate) 590 by encrypting the verification message(attestation contents) by its own private key (attestation serverprivate key). This message can then be decrypted by any verifyingrecipient device (e.g., the enterprise 530) with knowledge of public keyof the attestation server (which is known to everyone as it is public).Said differently, the verifying recipient device is caused to confirmthat the source data has been attested to by the attestation serverbased on applying the attestation server public key to the signedcertificate. Since the public key of the attestation server decrypts themessage, it is proof that only the attestation server (the only entitythat knows the attestation server's private key) could have written andsigned this verification message.

Notably, as shown in FIG. 5 , similar zero-knowledge storage andreporting of the PII information may also be performed by the AVS serverfor sharing reports with the compliance device 550, e.g., sharing KYCPII information with the government for flagged financial transactions.For instance, the compliance device 550 may send a report request 592 toan enterprise 530 (e.g., a compliance report) in response to any numberof triggers. Since the mobile device 520 also has obtained thecompliance device's public key (Gov PubK) 593, it can then also create acompliance-device-based rekeying key 594 through an encryptingcombination of the source decryption key (e.g., private key, U PriK) ofthe source device and the compliance device public key (Gov PubK).Accordingly, by sending the compliance-device-based rekeying key 594 tothe storage server 510, and in response to the report request 592, thestorage server re-encrypts (e.g., is caused to re-encrypt) thesource-encrypted source data 586 (and optionally other report-relateddata) with the compliance-device-based rekeying key 594, where there-encrypting results in the source/PII data being encrypted with thecompliance device public key (compliance-device-based encrypted sourcedata 595). Note still that the storage server is unable to decrypt thesource data encrypted with the compliance device public key (i.e.,compliance-device-based encrypted source data 595). The storage server510 may then send the compliance-device-based encrypted source data 595to the compliance device 550, which can then apply its own private keyto obtain and process the user's identity information (and optionallyother report data) from the previously encrypted source data (i.e.,decrypting the compliance-device-based encrypted source data using acompliance device private key of the compliance device).

As mentioned above, and with reference now to environment 600 of FIG. 6, in addition to original onboarding attestation of a particular user,there are challenges presented when verifying a user 605 (e.g., a user605 a via the mobile device 520 with an AVS client app 525 or a user 605b without the app 525) via web/SMS 660 or PSTN 665 connecting to acontact center 635 (a human and/or IVR), whether inbound or outbound. Inparticular, the challenge addressed by the techniques herein, and asdescribed in greater detail below, is to determine whether theconnecting user is a verified bank-authenticated(enterprise-authenticated) user or a generic non-verified user. Also,the techniques herein address whether an unverified connecting userattempts to appear as a verified connecting user, and how to mark it asan “attack”. Furthermore, the techniques herein may detect the level ofthreat/attack, e.g., via a spoofed call ID, and may change the requiredlevel of MFA/authentication based on that level of threat (i.e., for theappropriate level of identify assurance). Additionally, the architecture600 illustrated in FIG. 6 assures that the called party, in an outboundscenario, is actually being contacted by the enterprise indicated by thecaller ID and not by a hacker pretending to be that enterprise. In yetanother aspect of the embodiments herein, the enterprise does not needto disclose to the called party any private secured information otherthan the caller ID in order to assure the caller that they are beingcontacted by the enterprise that the caller ID claims. This preventsleakage of information in case the mobile device is answered by a partyother than the intended party, particularly for unexpected calls (whereexpected, e.g., requested calls, may give the called party furtherconfidence that the enterprise is in fact who they claim to be, sincethe call may be in response to or at a requested time of a call-back.

According to the techniques herein, to verify a user, and thus toestablish an “AVS-verified” user (i.e., verified according to thetechniques herein), there are two primary use cases to follow below:

-   -   1. As illustrated in FIGS. 7-8 , a user calling through an        (embedded) AVS App, either a standalone verification app or an        app associated with a particular enterprise; or    -   2. As illustrated in FIGS. 9-10 , a user calling through a        mobile phone which has the AVS App installed.

FIG. 7 illustrates an example architecture 700 for user verification,particularly an inbound scenario where an “AVS user” 705 (a user withthe AVS app) calls from the AVS app itself. In particular (and asdenoted with corresponding step numbers in circles in the drawing):

-   -   1. A user 705 accesses the AVS app 525 on their mobile device        520 and is verified through authentication (i.e., is a verified        customer for this enterprise contact center). The authentication        may involve fingerprint, facial authentication, iris        recognition, password, challenge questions, or any other        authentication mechanism required by the AVS authentication.        Note that the authentication may specifically take place through        an API 725 with an MFA module 726. Note also that the user may        be calling by invoking phone communication module 727 via API        725 from an AVS generic application or from a specific        enterprise application (which embeds an AVS App), e.g., the        enterprise is a bank, and the user is calling from the bank's        own mobile application.    -   2. At this time:        -   a. the AVS app may alert the AVS Access Control Gateway            (ACG) 734, e.g., via the AVS server 510, about an incoming            contact from a verified user ID (e.g., in response to a            contact initiation by the verified user);        -   b. the verification of the authentication/MFA is sent to the            AVS server;        -   c. and then the user initiates contact via Web/SMS 660            (e.g., a specific address, which may be known publicly or            only via the app); or        -   d. else via PSTN 665 (e.g., a specific phone number, such as            “1-800-special #” as shown, which may be known publicly or            else only through the app—optionally using only an            internally known number as a number from which the ACD is            willing to accept verified contacts).    -   3. In response:        -   a. the AVS server 510 relays the notification to expect a            contact from an AVS verified user (including identification            such as caller ID, IP address, etc.) to the AVS access            control gateway (ACG) 734; which is then:        -   b. received over Web/SMS 660; or        -   c. received over PSTN 665.    -   4. Once the contact is received from the pre-verified user, the        AVS ACG 734 verifies that the contact is from the same user for        whom the notification has been received within a predetermined        time window, and determines that the contact was initiated by a        verified user. The AVS ACG then notifies the ACD 732 that the        incoming contact is from an authenticated/verified user.    -   5. ACD contact center 732 can then treat the user as an        authenticated contact (e.g., authenticated contact treatment at        agent 736, as opposed to unauthenticated contact treatment at        agent 738, which may be the same agent just with different        verification, or may be a different agent or routing for        unauthenticated users generally).

Note that transferring a call to an agent may have a message thatcarries relevant associated (e.g., minimal) data, such as an indicationthat the contact has been verified and authenticated, an Account Number,Name, MFA level, etc. According to the techniques herein, the messagedisplayed to the agent contains no password, no date of birth (DOB), orany other sensitive information. Abstraction of the customer PII asrelevant for the call (e.g., age group instead of DOB, VIP customerinstead of account balance and transactions, etc.), may, however, beincluded, if such information is deemed relevant to the particularcontact center.

Note further that for incoming calls, there are generally two optionshere: a.) the call center has a single incoming number, e.g., 1-800-num1number, and all calls to the contact center are coming through thatnumber and through the AVS ACG; b.) the call center has two numbers: onenumber, e.g., 1-800-num1, which is configured in the AVS client and isintended for use by AVS clients and another number, e.g., 1-800-num2,which is a public number for generic non-authenticated callers to thecontact center. In this scenario, only those contacts that arrive at thefirst number, e.g., 1-800-num1, are processed by the flow describedabove (provided they were alerted by the AVS server). Contacts arrivingat the second number, e.g., 1-800-num2, are marked as unverified, andare treated as contacts from un-authenticated callers.

In case an unauthenticated caller, e.g., a caller without an AVS client,gets hold of the first number, e.g., 1-800-num1, and uses it to contactthe call center, the call is received at the AVS ACG. In response, theAVS ACG 734 starts a timer 712 to monitor a predetermined time window.Since the AVS server 510 does not get a notification from the AVS client525 within a pre-configured time-window, the timer 712 in the AVS serverexpires signaling to the AVS ACG that the call is from anunauthenticated caller. The call is then transferred for treatment as anunverified caller. Also, if the contact is received at the first number,e.g., 1-800-num, the contact may be marked as a potential fraudulentcontact.

Those skilled in the art should recognize that each time a call arrivesat the AVS ACG, the AVS ACG sends a message to the AVS timer whichstarts the measurement of preconfigured time-window. If a notificationarrives from the AVS client alerting of an incoming call from the samecaller ID before the timer expires, the timer is reset and the AVS ACGis notified of the incoming call as being a qualified call from anauthenticated caller. Similarly, if the notification from the AVS clientarrives first, the notification sets the timer for the pre-configuredtimeout. If the call from a caller with the same caller ID arrivesbefore the timer expires, the call is again qualified as arriving froman authenticated caller. Otherwise, if the timer expires, the call isqualified as coming from an unauthenticated caller and is marked as suchwhen it is transferred to the ACD.

FIG. 8 illustrates an example flowchart detailing a procedure 800 fromthe point of view of the access control gateway (ACG) in FIG. 7 above.In particular, the procedure starts in step 805, then when the ACGreceives an incoming contact in step 810, the ACG determines in step 815whether it has received a “verified” notification (msgs) from the AVSserver for the same caller ID, IP address, etc. If not, then in step 820the caller is marked for an “unknown caller” treatment and istransferred as such to the ACD to be treated by the ACD agent as anunverified contact. Alternatively, if the ACG receives an indicationthat the AVS server verified that contact in step 815, then the calleris deemed to be known and verified, and is marked for being treatedaccordingly in step 825 resulting in a frictionless treatment by the ACDagent.

FIG. 9 illustrates the example architecture 900 for user verification,now where an AVS user 905 (a valid but yet to be authenticated customerfor this enterprise), with the AVS app 525, calls the contact centerdirectly from a mobile phone 520 (rather than from the AVS client 525).As shown:

-   -   1. A (yet-to-be-determined-as-verified) user 905 gets hold of        his/her mobile device 520.    -   2. The user connects (e.g., via Web/SMS 660, or PSTN 665) to the        contact center at enterprise 530 directly via the mobile phone        (e.g., using the dialer of the mobile phone and directly dialing        the call center number, e.g., 1-800-num1, or by texting/sending        SMS message to the same number).    -   3. As the contact arrives at the AVS ACG 734, it sends a message        to the AVS server 510 notifying it of the incoming contact. This        notification starts a timer 712 with a pre-configured duration        in the AVS Server.    -   4. The same (or a second dedicated message) triggers a txt or        SMS message from the AVS server 510 to mobile device 520 (of the        user which initiated the contact in bullet 2 above) requesting        authentication. In accordance with a specific example        embodiment, the AVS server and the AVS client maintain a        dedicated encrypted connection via which the message is        communicated. Notably, the message sent can also be a branded        notification message that is sent from the mobile AVS app 525        (e.g., where this type of message will be seen by the customer        as more likely being from the enterprise).    -   5. When the client 905 sees the indication he/she invokes the        AVS client 525 and authenticates himself using the AVS client        (note that the AVS application may be invoked by a bot 925 to        initiate MFA queries).    -   6. Upon verifying the authentication, the AVS client 525 replies        to the AVS server 510 that the caller 905 has been        authenticated.    -   7. Prior to the timer 712 expiring, the user verification is        sent to the AVS server.    -   8. In this case, the verification of the caller is sent to the        AVS ACG 734 and the timer is disarmed. Since the user is        verified, he/she is given authenticated contact treatment by the        contact center, accordingly. That is, once the contact is        received from the pre-verified user, the ACD contact center 732        can then treat the user as an authenticated contact. (Note again        that transferring the call to agent 736 may carry associated        data, e.g., Account #, Name, MFA level, as well as abstracted        PII information, but still no password, DOB, or other sensitive        info.)    -   9. However, if the notification from the AVS client does not        arrive before the timer 712 expires (or does not arrive at all),        the timer expires and a timer expiration notification is sent        accordingly to the AVS ACG 734.    -   10. Upon receiving the notification that the timer had expired,        the incoming contact is marked as a contact from an        unauthenticated user. The contact is transferred to the ACD and        is treated accordingly with a treatment reserved for        unauthenticated contacts (e.g., by agent 738).

FIG. 10 illustrates another example flowchart detailing a procedure 1000now for FIG. 9 above. Here, the procedure starts in step 1005, and thenwhen the ACG receives an incoming contact in step 1010, it determineswhether it has previously received a verified acknowledgment messagefrom the AVS server in step 1015 (e.g., if an installed AVS client isrunning and has verified the identity). If not, and if step 1020determines that the AVS app is not installed on the mobile phone (e.g.,at least for this user, or is not associated for this user with thisenterprise), then the caller is treated as an unknown caller in step1025. However, if the caller is verified by the AVS app in step 1015,then the caller is treated as a known and verified caller in step 1030.

In the event the caller is not verified first by the AVS server in step1015, but the user does have the AVS client in step 1020, e.g., with theverification application on their mobile device (and the AVS client ofthe user is associated with the enterprise), then the AVS applicationmay be invoked (e.g., to activate a non-running/non-open application),such as by a bot or by a message from the AVS server in step 1035 toinitiate MFA queries in step 1040 (e.g., asking for a biometric proof ofidentity through the application). If at this point the MFA can verifythe caller in step 1045, then the caller is marked as an authenticatedcaller and is given verified (authenticated) caller treatment in step1050. On the other hand, if not, then the caller may be marked as apotential attack in step 1055 (i.e., has the AVS application, but cannotbe verified by MFA 726).

FIG. 11 illustrates the architectural flow 1100 for such a non-verifieduser. As shown:

-   -   1. A (yet-to-be-determined-as-unverified) user 1105 gets hold of        a mobile device 520.    -   2. The user connects (e.g., via Web/SMS 660, or PSTN 665) to the        contact center 530 by using the dialer of the mobile phone        (phone module 727) and directly dialing the call center number,        e.g., 1-800-num1, or by texting/sending SMS message to the same        (or other corresponding) number.    -   3. As the contact arrives at the AVS ACG 734, it sends a message        to the AVS server 510 notifying it of the incoming call. This        notification starts a timer 712 with a pre-configured duration        in the AVS Server.    -   4. The same (or a second dedicated message) triggers a text or        SMS message from the AVS server to mobile device 520 (of the        user 1105 which initiated the contact in bullet 2 above)        requesting authentication.    -   5. Either because the user who initiated the contact does not        have an AVS client on his mobile device or because the user has        an AVS client but fails to authenticate himself as instructed, a        verifying message is not returned from the mobile device to the        AVS server.    -   6. Consequently, the timer expires before the user can be        verified, and a timer expiration notification is returned to the        AVS ACG 734. Note that the techniques herein may also detect the        level of threat or “attack”, e.g., via the spoofed caller ID or        otherwise, and may change a required level of authentication/MFA        based on that level of threat (e.g., requiring facial        identification, rather than merely a passcode). For example, if        the system detects that a caller presents a valid caller ID that        belongs to the enterprise's customer, e.g., a bank customer, but        failed to authenticate themselves, the system keeps track of        this event and marks it as an attempt to misuse the caller ID.        The system can then ask a caller with the same caller ID to        authenticate themselves with additional factors such as voice        recognition, facial recognition, etc.    -   7. Since the user is not verified, the contact is marked as        unauthenticated contact and the contact is routed for        unauthenticated treatment 738 by the contact center 732,        accordingly.

Similar to FIG. 10 , FIG. 12 illustrates an example flowchart forprocedure 1200 adding the demonstration of the timeout for AVS not beinginstalled on the mobile device, and for the potential attack level beingincremented (e.g., per caller ID), as mentioned above. As illustratedand detailed below, when the timer in the AVS Server times out, thesystem concludes that the contact is from a user who has not beenauthenticated and as a result the contact is routed for treatmentreserved for unknown/unauthenticated contacts.

Specifically, the procedure 1200 starts in step 1205, and then when theACG receives an incoming contact in step 1210, it determines whether ithas received a verified acknowledgment message from the AVS server instep 1215 (e.g., an AVS app is installed and has verified the identity).If not, and if the AVS app is not installed on the mobile phone (e.g.,at least for this enterprise) in step 1220, then once the timer in theAVS Server times out in step 1222, the caller is treated as an unknowncaller in step 1225. If the caller is verified by the AVS app in step1215, then the caller is treated as a known and verified caller in step1230. If the contact was directed at a dedicated number e.g., 1-800-Num1which is reserved for calls/contacts from the AVS client the callattempt is identified as a potential security threat and is dealt withaccordingly.

In the event the caller is not verified first by the AVS server in step1215, but the user does have the AVS client in step 1220, e.g., withverification application on their mobile device, then the AVSapplication may be invoked (e.g., activating an otherwiseun-opened/minimized/non-running application) by a bot or by a messagefrom the AVS server in step 1235 to initiate MFA queries in step 1240(e.g., an MFA IVR/agent asking for a proof of identity through theapplication). (In accordance with another example aspect of thetechniques herein, the AVS client is always active on the mobile deviceand does not need to be explicitly invoked.) If at this point the MFAcan verify the caller in step 1245, then the caller is marked as anauthenticated caller and is given verified/known caller treatment instep 1250. On the other hand, if not, then the caller may be marked as apotential attack in step 1255 (i.e., has the AVS application, but cannotbe verified by MFA). As noted, the techniques herein may mark attemptsto misuse a caller ID and may increment a potential attack level (e.g.,to cause the agent to be on higher alert, or requiring greaterauthentication or limited services) in step 1257.

FIG. 13 illustrates an example architecture view 1300 of the contactcenter 732 of the enterprise 530 making an outbound call to a user'sphone number (or other contacting identification, such as for VoIP,video calls, text message, etc.). As shown:

-   -   1. The ACD contact center 732 initiates a contact to a customer        (“called user”) 1305 (e.g., based on a trigger, a queue, etc.).    -   2. The contact is extended by the AVS ACG 734 to the user (e.g.,        via web/SMS 660 or PSTN 665).    -   3. At substantially the same time, the enterprise also initiates        an outbound called party verification process through the AVS        server 510, as well as a process to reassure the called party        that the contact request is from a valid enterprise and not a        spoofed call.    -   4. An SMS message may be sent from the AVS server 510 to the        caller ID of the party (mobile device 520 of user 1305),        requesting authentication.    -   5. Alternatively, or in addition, if the AVS application 525 is        installed/running, a notification may be sent from the AVS        server directly to the AVS client app, requesting        authentication. In either case, whether the AVS client was        running on the mobile device or is invoked based on the request        from the AVS Server, the AVS client exchanges messages with the        AVS server, verifies that the contact was initiated by the        enterprise, e.g., the bank, and provides the called party with        assurance that the incoming contact is not from a hacker who        spoofed the caller ID of the enterprise, e.g., the bank.    -   6. The solicited verification may then be performed (successful        or not).    -   7. A timer 712 may have been set to allow a set amount of time        for a successful authentication to occur.    -   8. The determination as to whether to acknowledge the answering        party 1305 as the verified intended user (for authenticated        contact treatment 736) or an unverified (for unauthenticated        contact treatment 738) may then be returned from the AVS ACG 734        to the ACD contact center 732 and associated agent. In case the        timer 712 expires before a message is received from the AVS        client attesting that the intended caller has been        authenticated, the contact is marked as an unauthenticated user.

FIG. 14 illustrates an example flowchart detailing the outboundprocedure 1400 described above in FIG. 13 . Specifically, once startingin step 1405, the ACD initiates contact via the AVS ACG (1, 2, and 3above) in step 1410, and then the AVS server attempts to establishconnection with the AVS app on the client (4 and 5 above) in step 1415.If the AVS app is running on the mobile device and the connection isestablished in step 1420, then MFA queries are made on the app in step1425, and the user may be verified using the MFA module of the AVSclient (6 above) in step 1430, resulting in a verified/known callertreatment in step 1435 (8 above). If the user is not verified by the MFAmodule of AVS client in step 1430, by an expired timeout (7 above) instep 1440, then the called party is marked as unverified in step 1445,and treated accordingly (8 above), despite the called device having theAVS app installed and running (e.g., someone else may have answered thecall).

Conversely, if the AVS app is not running on the mobile device in step1420, then it may be invoked (activated) via a bot and the AVS server instep 1450, and notifications (alerts) or SMS/text messages may be sentto have the user invoke the AVS app on the mobile device in step 1455.In accordance with another embodiment (not shown) the AVS clientapplication always runs in the background. If the AVS app is determinedto be running in step 1460 before a timeout in step 1465, then MFAqueries may be made in step 1425 as mentioned above. However, if the AVSapp fails to establish communication with the AVS server (e.g., it doesnot get started) in step 1460 before the expiration of the timer in step1465, then the person answering the call is marked as unauthenticated instep 1470 and is treated as an unverified person (8 above), who notablymay not have the AVS client installed or running.

For a better understanding of the techniques herein, FIGS. 15A-15Iillustrate an example of illustrations related to a visual walkthroughof one or more embodiments herein from the perspective of a user'smobile application (e.g., for a bank) and of a contact center agent'sapplication (e.g., desktop app). As mentioned above, the techniquesherein establish a secure and private data channel between a user'smobile app and a contact center app, which provides authentication priorto connecting a call/communication channel (e.g., biometric-basedauthentication or otherwise), behavioral and historical call routing,and zero knowledge requests for information. In addition, the techniquesherein improve outbound connect rates with branded messages andfrictionless authentication. Moreover, authenticating the to-be-verifiedparty (called party or calling party) without involving agent results inimproved efficiency/productivity of the enterprise/call center.

As shown in FIG. 15A, an example call center application such as anagent desktop (view 1505) is shown illustrating various statusinformation which is provided to the contact center agent about a givenuser, who at this point, remains un-contacted and un-verified. The callcenter agent could be manually examining a customer's information, orelse an automated alert may have triggered a reason for connecting witha user, such as a suspected fraud confirmation, or any other reason. Inanother example, a queue of users/customers may need to be called (e.g.,for larger lists of calls that need to be made, such as for marketing,account changes, product recall, medical alert, etc.), and in thisinstance the techniques herein may be integrated with contact centercomputer telephony integration (CTI) to recognize when a user's numberis approaching the top of a list manager's call queue.

Either by manually pressing a notification button in the agent's app(e.g., the “notify fraud” button 1506 at the bottom of the app), or elsethrough programmatic triggers, a customizable (e.g., branded)notification may be sent to a user's preferred device(s) (e.g., mobiledevice view 1510 with pop-up notification 1511) to alert them of anupcoming call.

When the user taps the notification, it may open the associated companyapp (e.g., bank app), which as shown in FIG. 15B (view 1515) may requestauthentication of the user (e.g., authenticating with facial recognition1516, fingerprint, etc.). When the AVS app/client is invoked it connectswith the AVS server and over a secured connection verifies that thecontact is being initiated by the enterprise, e.g., by the bank. Thecalled party is then notified that the incoming contact request is froma valid enterprise, e.g., the bank, and not from a hacker who attemptsto spoof the caller id of the bank. Upon authentication, the user'sapplication may then be opened (view 1520), and the user may bedelivered to a notification center to see more details regarding thisnotification (e.g., and any other previous notifications), as shown inFIG. 15C (view 1525, notifications 1526). Now, the user has theopportunity to tap an option to “request a call about this” (1527),which invokes an authenticated contact treatment and ensures that theuser will not be placed at the end of the queue for a generic agent whois unaware of any unique account needs, but rather an agent who is readyto discuss the particular notification and who knows that the user isalready verified.

As shown in FIG. 15C view 1530, the user may be prompted (prompt 1531)to request to be called now, or a callback for later time (e.g.,bringing up FIG. 15D, view 1535, for selecting a suitable date and timein window 1536). When requesting to be called now, since the user isalready biometrically authenticated, the user can bypass anyknowledge-based authentication (KB A) entirely when called by thecontact center. Notably, when being called by the contact center, thecontact center's caller ID will appear (FIG. 15D view 1540, ID 1541),and the call will be at the expected time (now or when requested). Insome example embodiments, the display includes language mentioning tothe called party that this call is in response to their request for acall, e.g., regarding the fraud notification (not shown).

On the agent desktop app (FIG. 15E, view 1545), it can now be seen thatthe caller status has changed to verified (status 1546), while on themobile device (FIG. 15E, view 1550), a banner 1551 shows that the useris now on a verified phone call with a particular agent (e.g., name andID number) and not on a call with a hacker spoofing the contact centerof the enterprise.

Once a secure data channel is established between the agent and thecalled party, the agent has an alternative to asking the user to sharesensitive details, such as by sending a request to verify proof ofhaving a credit card (e.g., clicking “send request” on the agent app forcredit card verification), without having to send the information to theagent. For instance, as shown in FIG. 15F (view 1555), after an agent,on their view 1560 of FIG. 15F, clicks “send request” 1561, the user isprompted to enter security code for the credit card in a pop-up banner1556. Once entered correctly, then the agent desktop may pop up anotification 1562 as confirmation that this card has in fact beenverified, without exposing that sensitive information to the agent.

In addition to the credit card, the agent can also ask for otherinformation, such as social security number (SSN), password,re-authentication (e.g., facial recognition again, or another biometricverification), and so on, as shown in FIG. 15G (view 1565, drop-down box1566). In each of these cases, the user may authenticate the informationon their mobile app, without exposing the information to the agent.

Turning now to an example where the user does not originally accept(push, react to, etc.) the notification sent in FIG. 15A (view 1505)above (e.g., within the 15 minutes), as shown in FIG. 15G (view 1570),the agent may click a “call” button 1571 to directly call the user(shown in view 1570 as clicked and “calling”). The user then receivesthe call (e.g., from the verified caller ID 1576 of the bank, as shownin FIG. 15H, view 1575). It should be noted that because the AVS serverconnected with the AVS client on the user's mobile device, the displayon the user's mobile device may be the AVS client rather than the simpleuser interface of the phone. Upon answering the call the user may beprompted to log into their mobile app (e.g., “If you would like fasterand more personalized experience, please log into your bank app on yourmobile phone to verify yourself”). If the user so chooses, then as shownin FIG. 15H (view 1580), he/she may be prompted to verify his or heridentity with the AVS app (e.g., Face ID 1581), bringing the user to theapp landing page as shown in FIG. 15I (view 1585) with the banner 1586at the top reassuring the user that he is talking with the actualenterprise, e.g., the bank, and not with a hacker spoofing the bank.Similarly, the agent's desktop app also now indicating that the calledparty has been authenticated and verified, as shown in FIG. 15I (view1590, status 1591).

Notably, in the event the user begins the process by calling thebank/company directly, such as by calling the number of the back ofhis/her credit card instead of using the mobile app, then the contactcenter may again prompt the user to log into his or her mobile app(e.g., either as a default, or else after the call center, e.g., usingCTI or an integrated module, recognizes that this user had a mobiledevice with an AVS client and/or the phone number is associated with avalid account). If the user complies, then again this results in averified user before a contact center agent is added to the call (i.e.,authenticating via the mobile app without sharing private informationwith the agent, and all done “pre-answer”, i.e., before the agent wasadded to the call).

In one alternative or additional embodiment to the above description, asession may be initiated as described above, but now while the agentinteracts with the verified customer, assume that the customer mayrequest something that would prompt/require a higher level ofsecurity/verification. For instance, a first level of verification mayallow for information sharing about account balances, while a secondgreater level of verification may be needed for withdrawals or transfersof a large amount of money, e.g., sums larger than $10,000. As a result,either based on agent trigger or based on heuristics that have to dowith the forthcoming transaction (e.g., withdrawal of a large sum ofmoney, or otherwise), the techniques herein may ask the user (caller)for yet another authentication factor/modality, e.g., facial recognitionwhen the previous authentication was merely a passcode or fingerprint.Said differently, this embodiment allows the authentication mechanism tobe dynamically tuned by the system to ask and convey strongerauthentication based on dynamic needs of the communication interaction.

In particular, in certain embodiments herein, even though a user mayalready be authenticated and verified, the techniques herein may allow averifying entity (e.g., the enterprise/call center/agent) to request analready verified user to provide additional information for additionalsecurity. For instance, this higher level of assurance/security (i.e.,an “increased assurance of verification of the identity”) may be neededin various situations, such as, for example, when going from aconversation about an account to requesting a financial transaction, orwhen going from a level of assurance where transactions below $10,000are acceptable based on the original authentication, but once arequested transaction is above $10,000, then a higher security standardmay need to be met. Such verification levels (levels of assurance ofverification of an identity) may be based on an additional securitymeasure (e.g., asking for another security answer), or based on morestringent security measures (e.g., a facial recognition being moresecure than a password), or based on a greater number of securitymeasures (e.g., going from a password to a Social Security number and amother's maiden name), or any combination thereof. Also, according toembodiments herein, the additional authentication may be requestedautomatically (i.e., requesting the increased assurance of verificationof the identity occurs automatically in response to one or more triggersduring the communication) by the enterprise or the call center, and doesnot need intervention by a person/user to trigger this increasedassurance.

According to the techniques herein, therefore, with all contactscenarios above, the agent's desktop shows all of the rich informationabout the individual user that the agent is connected with (e.g., recentapplication views, recent contacts, recent notifications, etc.), andwhether the user's identity has already been verified, such as accordingto the techniques described in greater detail above.

By establishing this secure private data channel between this specificuser and specific security module in the AVS server and/or the AVS ACG,the techniques herein have unlocked access to a rich set of contextualhistorical and behavioral data that can be used to affect call routinglogic and better inform this agent about a unique caller's background,needs, and current situation. Similarly, in an outbound scenario, byassuring the called user that the call is coming from a validauthenticated enterprise, such as a bank, a doctor's office, etc., theuser is more inclined to accept the call resulting in higher callcompletion rate for the enterprise.

FIGS. 16A-22 illustrate example workflows between a user's end device(e.g., smartphone, tablet, etc.) and the contact center's application(e.g., agent desktop app).

As shown in FIGS. 16A-16D, a first example 1600 for pushing an outboundrequest for communication is shown (i.e., the contact center pushes anotification to the user). As shown, in anticipation of an upcomingcall, the bank contact center's outbound contact list manager pushes anotification to the user to alert him/her about an upcoming call (view1605, notification 1606). The user taps the notification, which launchesthe bank's app (view 1610), which triggers the native authenticationprotocol(s) 1611, e.g., FaceID (facial recognition) in this case. Onceauthenticated, the authentication notification is sent to the contactcenter via the AVS Server and the user lands on their primary homescreen (view 1615), and the user sees his/her notification window (view1620), which shows the most recent notification in a list ofnotifications 1621 that initiated this process.

The user taps “Request a call about this” alongside the notification,and then, as shown, the user makes the choice whether they'd like toreceive a call now or schedule it for a later date and time (view 1625,pop-up 1626). If they choose “Schedule for later”, the example flowmoves to view 1630, and the user can select from available (e.g., 15minute) intervals (pop-up 1631). Shortly after (requesting a call “now”and bypassing view 1630), or at the scheduled date and time (set in view1630), the user receives a call from the bank (complete with a matchingcaller ID) (view 1635, ID 1636), at which time the bank agent may saysomething like, “Hello Brett, this is John from the Bank. Thank you forrequesting this call about recent transactions on your account. Youridentity has already been verified through your mobile app, and if youlook at your app, e.g., bank app or AVS app, you'll see you are now on averified phone call.” In the app, the user can now see that they are nowon a verified call (view 1640), as well as the name and ID of theparticular agent from the bank (window 1641). Verified treatment maythen proceed with the called user, accordingly.

FIGS. 17A-17B illustrate another example 1700 where the user ignores theinitial notification. For instance, in anticipation of an upcoming call,the bank contact center's outbound contact list manager pushes anotification to the user to alert them about an upcoming call (view1705, notification 1706), but in this example, the user does not takeany action. At a later time, the user receives a phone call with thecaller ID of the Bank (view 1710, ID 1711), at which time an agent orautomated prompt may prompt the user to log into the app, such as bysaying “Hello, this is the Bank. If you′d like, you can receive fasterand more personalized service on this call by logging into or bringingup your bank mobile app to verify yourself.” The user opens their appand authenticates themselves (view 1715, FaceID 1716). Once theiridentity has been verified, the user may be instructed on the phone thatan agent will be with them momentarily, and once an agent joins thecall, the user and the bank's call center agent can again see that theyare both now on a verified call (view 1720, agent ID window 1721). Here,verified treatment of the called user may again proceed.

FIGS. 18A-18D illustrate an outbound call being requested from the userin example 1800. For instance, as shown, the user opens their mobile app(view 1805), and authenticates himself/herself using his/her mobile AVSapp or bank's app (view 1810, illustrative FaceID 1811). If the usertaps the phone icon in the top left corner (view 1815, icon 1816), thenonce the notification screen pops up (view 1820, pop-up notifications1821), the user may click “Request call about this” next to one of theirnotifications. As shown in view 1825, the user makes the choice whetherthey'd like to receive a call now or schedule it for a later date andtime in selection window 1826. If they choose “Schedule for later”, theycan select from available dates and times (view 1835, selectable options1836). The user receives a call from the bank (complete with a matchingcaller ID) (view 1835, ID 1836), either “now” or at the scheduled time.The bank's agent can see that the user is verified and can see theparticular notification the user had originally selected to discuss (notshown). Since the user's identity has already been verified by his/hermobile app, he/she can open his/her app to see that he/she is now on averified phone call (view 1840, verification window 1841). Once again,the user can now be treated as verified during the call.

FIG. 19 illustrates an example 1900 for when a user calls the bank'sphone number directly (e.g., a number on the back of a credit card). Forexample, the user may choose to call the phone number on the back oftheir credit card, and may then dial it on their mobile device/phone(view 1905). Once answered (e.g., agent or automated), then the user maybe prompted to receive faster and more personalized service on this callby logging into (or bringing up) their bank's mobile app and verifythemselves. Once the user opens their AVS app or bank's app andauthenticates themselves (view 1910, authentication 1911). If theiridentity has been verified with the system, an agent or automated systemcan then treat the caller as verified. By opening the mobile app, theuser can now see the indication that they are now on a verified call(view 1915, verification confirmation 1916).

FIGS. 20A-20B illustrate a further example 2000, where the user hasopened their app, but has not yet logged in or alternatively beenauthenticated (i.e., an inbound call pre-login or authentication). Inthis example, as shown in view 2005, the user launches their mobile appand may have the option to perform various “unsecure” operations 2006(such as finding local bank branches, reading informational articles,accessing frequently asked questions (FAQs), etc.). The user may, atsome point of their navigation, tap a “Call” button 2007 on the screen.This may now trigger the app to authenticate the user if not alreadyauthenticated (view 2010, authentication 2011). In other words, when auser wants to use the app, he/she may first authenticate himself/herselfbefore doing anything, including make a call, or else as in example2000, a “call” button may be available during unsecure use of the app,and prior to authenticating and thus entering a secured session. Onceauthenticated, the user's phone dialer is opened with the Bank's numberentered and ready to call (view 2015). An automated system or live agentmay then engage the user as a verified user, e.g., “Hello Brett, this isJohn from the Bank. Your identity has already been verified through yourmobile app, and if you open your app you'll see you are now on averified phone call. How can I help you today?” The user can see thatthey are now on a verified call (view 2020, verification information2021), and be treated accordingly.

FIGS. 21A-21B illustrate a further example 2100 where now the user hasopened their app and has logged in (i.e., an inbound call post login).In particular, as shown in FIG. 21A, the user opens their mobile app(view 2105), and authenticates themselves to their mobile app (view2110, authentication 2111). Now, while in secure view of the app (view2115), the user has the option to tap a phone icon 2116 (e.g., as shownin the top left corner). As shown in FIG. 21B in view 2120, if the userselects this icon, a popup notification window 2121 may allow the userto click a “CALL” button 2122 at the top of their call/notificationwindow. Note that other illustrative techniques for initiating a callfrom a mobile app will be appreciated by those skilled in the art, andthose shown herein are merely examples. The user's phone dialer is thenopened with the Bank's phone number entered and ready to call (view2125), or optionally auto-dialing the number. Upon contact centeranswering of the call, the user's identify is already verified, and byopening the app, the user can see that they are now on a verified call(view 2130, verification 2131), and will be treated accordingly.

As still another example, FIG. 22 illustrates an example “zeroknowledge” request and verification process 2200. For instance, assumethat the contact center or the agent of the call center, presently on averified phone call with a customer, sends a request to the user'sdevice for the user to verify the last 4-digits of their social securitynumber (view 2205, drop-down box 2206 selecting SSN for verification).Note that as shown in the caller status 2207, the user is alreadyverified, and thus this may be an example of an additional level ofverification (e.g., based on higher security needs before proceedingwith a particular transaction or sharing certain information). In view2210, the user receives the request (pop-up window 2211) and can chooseto confirm the last 4 digits in their app rather than telling them tothe agent. The agent cannot see any digits of the customer's SSN, butthey receive a notification that the 4-digits that the customer enteredhave been verified by the bank's back-end system (view 2215,verification notification 2216). Note that the verification status 2207may remain “verified”, or may indicate a certain level of verification(not shown).

Other example workflows may be presented, and those illustrated hereinare not meant to be limiting to the scope of embodiments afforded by thetechniques herein.

Notably, for one additional embodiment, it is important to point outthat one of the reasons that companies ask for new identity informationevery time a call is transferred between applications or between agentsis that the security teams are reluctant to allow identity data to betransferred via a CTI link, since they either don't understand, don'ttrust, or don't have the proper security. As such, in this particularembodiment, with reference to environment 2300 of FIG. 23 , an identitytoken 2310 may be created as soon as the customer 2305 is verified,rating the veracity of the customer verification (e.g., from fullytrusted down to completely unverified), and moving the identity tokenaround between apps and agents as the customer is moved around (e.g.,from agent 2331 to agent 2332). As shown, the token is generated by theAVS client 525, but in other embodiments, the token may be establishedby any trusted authority receiving the verification (e.g., the AVSserver 510 or enterprise 530). In accordance with yet another aspect ofthe embodiments herein, rather than passing the token 2310 between thedifferent apps/agents, the AVS client application 525 on the mobiledevice may issue a new security token 2315 on demand in response to anyauthenticated application that requests it. This prevents a single tokenfrom being over-used and compromised (i.e., each verification token is“unexchangeable”). These embodiments would thus allow for greateracceptance of providing verified identity, while alleviating a lot ofperceived customer friction such as customers being asked by eachdifferent application/agent on a single phone call to be authenticated.

Advantageously, the techniques described herein thus provide accesscontrol, assurance that the user is called by a valid enterprise ratherby a hacker spoofing the ID of the enterprise, as well as userverification for a contact center. In particular, the techniques hereinallow for both end-users (e.g., a customer and a company or any twoend-users) to verify their identity to each other through frictionlessuser experiences with the stringent security required to preventimproper use or abuse of their data. Also, the techniques herein furtherprovide consumers greater control over who has access to their secureinformation, such as by authenticating through an app without sharingsecret information with the company or its representatives (e.g.,completely removing the agent from the call authentication). Thetechniques herein also reduce average call handling time, which benefitsthe user's experience as well as the company's expenses (e.g.,cost-per-minute, staffing needs, etc.). Moreover, the techniques hereinincrease self-service containment, as customers are not expected toenter pins, account numbers, or answer knowledge-based authenticationquestions. Additionally, by assuring that a call is arriving to a userfrom a verified enterprise, e.g., a bank, and not from an entity thatspoofs the caller ID of the enterprise, the rate of call completion(answered/accepted calls) of outbound calls from the enterpriseincreases, resulting in higher call center productivity.

In addition, the solutions herein thus offer highly reliable pre-answeras well as post-answer authentication (e.g., adaptive authentication/MFAto prevent cross-channel fraud, including account takeover), that notonly verifies users seamlessly, but also protects against internalattacks (avoiding the contact center agent from needing or seeing thecustomer's PII), and also avoids the AVS server from having knowledgeof, or even access to, the connecting user's PII. For instance, whileMFA is a known technique for verification, sending a user a text messageor email to their device merely confirms the device, and not theparticular user. Moreover, most MFA techniques require the user toconvey the pin/code/answer to the operator at the other end of the call,which again may cause problems with regard to privacy if the operator isan unscrupulous party. On the contrary, the techniques herein usedifferent channels (communication and verification channels), andmaintain privacy of the various authentication factors used during thevalidation (in addition to the PII, and so on). Additionally, as theuser changes the nature of the ongoing transaction, e.g., the amount ofmoney to be transferred, the system may require a different level ofauthentication and consequently automatically invoke an additional MFAmeans. For example, the interaction may start with user authenticationbased on fingerprint. As the system detects that the amount of money theuser attempts to transfer is greater than a specific threshold, e.g.,$10,000, the system automatically and without intervention by a bankagent requests an additional authentication level by presenting the userwith, for example, a facial recognition demand.

It is important to note that the techniques herein are not limited toinbound user-to-enterprise communications or outbound enterprise-to-usercommunications, but may be generally applicable to any user-to-user(person-to-person) communication or device-to-device communicationswhere one device has an associated identity that needs to be verified tothe other device (or user of the other device). That is, the identity ofany entity (i.e., an identity of an entity associated with a particulardevice) may be verified herein, whether that entity is a person, adevice itself, an enterprise, and so on. Moreover, while the descriptionherein often refers to the example of a contact center (or call center)for an enterprise, the present disclosure also applies to anyinteraction with enterprises which either have or do not have a contactcenter. In addition, though mentioned above, it is worth pointing outthat both sides of a communication may request verification of the othercorresponding side, prior to or during the communication. For example,though the use-case above is generally directed to an enterprise (e.g.,bank) requiring verification of the customer, the techniques herein alsoallow the customer to request/obtain verification of the enterprise'sidentity as well (e.g., confirming that the customer is, in fact,talking to an agent of his/her bank). Also, while the description hereinoften describes the request for authentication to be invoked by anagent, it should be understood that the request may be invoked either bya person using a device or automatically by a device based on apreprogramed or configured policy.

FIG. 24 illustrates an example simplified procedure for providing accesscontrol and identity verification for communications between aninitiating device and a recipient device in accordance with one or moreembodiments described herein. For example, a non-generic, specificallyconfigured device (e.g., device 200, such as an AVS server 510) mayperform procedure 2400 by executing stored instructions (e.g., process248). The procedure 2400 may start at step 2405, and continues to step2410, where, as described in greater detail above, a server (e.g., AVSserver 510) receives, over a verification channel, a notification of acommunication on a communication channel between a first device and asecond device. In one example, the first device is an initiating deviceof the communication to the second device as a receiving device. Inanother example, the second device is an initiating device of thecommunication to the first device as the receiving device. Also, in oneexample, the notification is received from the second device, while instill another example, the notification is received from the firstdevice.

In step 2415, the server may correspondingly determine whether anidentity associated with the first device is verified. As described indetail above, this may involve such things as receiving a verificationof the identity from a verification service client application (e.g.,AVS app 525) on the first device over the verification channel,performing verification of the identity with the first device over theverification channel, invoking a verification service client applicationon the first device to obtain verification (such as initiating theverification service client application on the first device (e.g., a“pop up message), prompting the first device to install the verificationservice client application, and so on).

In step 2420, the server may then inform, to the second device over theverification channel, whether the identity associated with the firstdevice is verified, such that the second device is caused to manage thecommunication according to whether the identity of the first device isverified, as described in greater detail herein. The simplifiedprocedure 2400 may then end in step 2425.

Other procedures relative to providing access control and identityverification for communications, such as when receiving a communicationfrom an entity to be verified, when initiating a communication from anentity to be verified, when initiating a communication to an entity tobe verified, and when receiving a communication at an entity to beverified, are described in commonly owned, co-pending, U.S. patentapplication Ser. No. 16/861,663, filed on Apr. 29, 2020, entitledPROVIDING ACCESS CONTROL AND IDENTITY VERIFICATION FOR COMMUNICATIONSWHEN INITIATING A COMMUNICATION TO AN ENTITY TO BE VERIFIED, by Shaffer,et al., now published as US-2020-0259828-A1 on Aug. 13, 2020, thecontents of which being incorporated herein by reference in itsentirety.

—Conveying a Reason for a Call (from a Call Center)—

As noted above, one major problem faced by call centers today is thatwhen a user receives a call through conventional systems, the user oftendoes not answer their phone as they do not know with certainty who iscalling, why they are calling, or the urgency of the call.

The techniques herein, therefore, provide a method for conveying to thecalled party the validated caller's identity (e.g., caller ID) and,specifically, the reason for the call and/or the urgency of the call. Asdescribed above, an example unified architecture may provide a solutionto numerous issues faced by customers, and illustratively this samearchitecture may be used for the techniques herein. That is, unlikeother systems where each new feature requires major changes inarchitecture, the unified architecture described above may further beadapted to provide the additional techniques herein as they relate toconveying a reason for a call. Note, of course, that a standalone orother dedicated system may be used herein, and the unified architecturedescribed above is merely one example implementation.

FIG. 25 provides a simplified flow 2500 for conveying a reason for acall using the illustrative AVS architecture described above.

The process in FIG. 25 starts with the call center 732 identifying(either by an agent or automaticity based on a pre-programmed algorithm)a caller and a reason for placing the call (1). Similar to the processflow described above, a corresponding message arrives at the AVS accesscontrol gateway (ACG) 734. The AVS ACG 734 selects one of the freeoutbound lines (numbers) which are available for placing the outboundcall and sends a message to the AVS server 510 (2) notifying it of theintended call including a) the called party number, b) the reason forthe call, e.g., suspected transaction, change in privacy rules, etc.,and c) the outbound number that the system intends to use (e.g.,1-800-555-5555). In accordance with a specific implementation, themessages (1) and (2) include also an indicator for the urgency of thecall.

The AVS server 510 establishes a connection with the AVS App 525 runningon the mobile device 520 of the called party (3). The connection may be,and often is, established using an encrypted security token that wasshared between the mobile device 520 and the AVS server 510 during thetime when the called user established an account on their mobile devicewith the institute, e.g., a bank, a government, etc. In accordance witha specific implementation the secured connection between the device 520and the AVS server 510 in established and maintained continuously andnot in response to the AVS needing to send a message to the device. TheAVS server 510 sends over the secured connection a message to the AVSApp 525 informing it that a call is about to arrive at the mobile device520 from a specific caller ID for a specific call reason. In accordancewith a specific implementation, the AVS Server 510 may also forwards tothe device 520 an indicator about the urgency of the requested contact.

In accordance with one preferred embodiment, the message from the AVSServer 510 includes the number over which the institute intends to placethe outbound call, e.g., 1-800-555-5555 (4). This number is used then bythe AVS app 525 in the mobile device 520 to revalidate that the upcomingoutbound call from the call center 732 to the mobile device 520 isactually coming from the validated institute.

Once the AVS App 525 receives the notification about the upcoming call,the reason for the call, and/or an indicator about the urgencyassociated with the contact request, the outbound ACD/dialer is notified(8) and a contact with the called party is initiated (9) either via aphone call or via a text (txt) message.

According to normal operational processing, when the mobile device/phone520 receives an incoming call it is configured to compare the number ofthe incoming call against its internal directory. When the number existsin the directory, the phone is configured to display the caller's nameassociated with that number rather than (or in addition to) the phonenumber associated with the incoming call. However when the number of theincoming call is not found in the directory, the phone displays only thephone number of the incoming call. The techniques herein, however,modify this process flow. In accordance with one example embodiment,when the phone does not find the phone number of the incoming call(e.g., 1-800-555-5555) in the directory, it attempts to find it in theAVS App 525. In the case of a generic incoming call, the AVS App 525does not have any information about that incoming call and as such themobile phone displays the phone number of the incoming call. However,when the call arrives from the phone number that the AVS App 525 waspre-notified about, the AVS App 525 returns in the caller ID field thename of the calling institute augmented with the reason call, e.g.,“K2Bank calling about suspected activity in your account”. In accordancewith a specific implementation, the phone display provides also theurgency of the contact request. In accordance with yet anotherembodiment, the notification may include also an icon (generated by theAVS application, vouching that the contact request arrived from avalidated identity.

In accordance with yet another preferred embodiment, the phone isconfigured to first check and to resolve the user ID of any incomingcall with the AVS App 525. In accordance with this process flow chart,the AVS ACG 734 notifies the AVS App 525 of the incoming inbound calland the reason for the call. When a call arrives, the phone asks the AVS510 whether it is aware of a call from the specific number of theincoming call.

If the incoming call is from any number other than the number of theinstitute, e.g., bank, etc., AVS App replies that it has no informationabout the number of the incoming call. The number of the incoming callis then used to query the directory of the mobile phone. The processflow proceeds like with existing phones: If the number is in thedirectory, the phone displays the user ID associated with the number,otherwise, the phone displays the number associated with the incomingcall. However if the number of the incoming call matches the phonenumber that the AVS ACG provided, the AVS App returns the caller IDaugmented with the reason code received from the AVS ACG via the AVSserver, e.g., “K2Bank calling because of suspicious activity in youraccount.” Additionally, the AVS App may provide the user with anindication that the incoming number matches the number that the AVSserver sent/alerted the mobile device about the incoming contactrequest. In either case the user may reject the incoming call, acceptit, or alternatively the user interface may, and often does, present anoption for scheduling the call for a future time.

—Conveying a Reason for a Call (from a User)—

Similarly, another major problem faced by users of call centers today isthat when a user places a call through conventional systems, the callcenter requires the user to use an IVR or a Robotic Process Automation(RPA) with menus with which the user may be unfamiliar.

The techniques herein, therefore, provide a method for conveying to thecall center or to another called party the validated caller's identity(e.g., caller ID) and, specifically, the reason for the call and/or theurgency of the call. As described above, an example unified architecturemay provide a solution to numerous issues faced by customers, andillustratively this same architecture may be used for the techniquesherein. That is, unlike other systems where each new feature requiresmajor changes in architecture, the unified architecture described abovemay further be adapted to provide the additional techniques herein asthey relate to conveying a reason for a call. Note, of course, that astandalone or other dedicated system may be used herein, and the unifiedarchitecture described above is merely one example implementation.

FIG. 26 provides a simplified flow 2600 for conveying a reason for acall using the illustrative AVS architecture described above.

The process in FIG. 26 starts with the user 2605 invoking the AVSapplication 525 and entering the called party number/ID as well as areason for placing the call (1). In accordance with a specificimplementation the user may enter the urgency of the call. In accordancewith the one specific implementation, the reason for a call may be acommand or instruction that is intended to invoke an action an automatedor a manual action by the called target. Similar to the process flowdescribed above, as the corresponding message arrives at the AVS server510 (2), the server may request the AVS App 525 (3) to validate that themessage arrived from an authorized user. The AVS application 525 mayinvoke the MFA 726 (4) to ensure that the user of the mobile device 520is actually the one that has been previously authenticated by thesystem. The validation is then returned over the dialog connection (5).In accordance with a specific implementation, the MFA 726 is invoked bythe AVS application 525 as part of the process of entering the reasonfor the call and/or the command/instruction to the called party. In somespecific implementation the number that will be used by the caller isalso conveyed to the AVS server 510.

The AVS server 510 conveys the information to the AVS GW 734 oralternatively to the ACD 732 (6).

In accordance with one specific embodiment the call center uses its RPAor any other means to assess the availability of an agent to address theincoming request and if the required resources are available, the ACD732 instructs the ACG 734 to establishes a contact with the user (8),resulting in an outbound contact with the user (9).

Otherwise, if resources to handle the contact are not available in thecontact center, the contact center may notify the user of theapproximated wait time and place the call to the user as soon asresources become available.

Similarly, if the message from the user includes a command and/orinstructions, after the AVS server 510 validates that the instructionswere provided by an authorized and validated user, the AVS server 510passes the command to the ACD 732, e.g., to another server or to anotherendpoint where an appropriate action is taken automatically. Forexample, the validated and authorized user may transfer a specificamount of money from his account to pay for a bill.

In closing, FIG. 27 illustrates an example simplified procedure forconveying a reason for a call to a user device in accordance with one ormore embodiments described herein, particularly from the perspective ofa call center (e.g., a device of an organization). For example, anon-generic, specifically configured device (e.g., device 200) mayperform procedure 2700 by executing stored instructions (e.g., process248). The procedure 2700 may start at step 2705, and continues to step2710, where, as described in greater detail above, an initiating deviceof an organization (e.g., a call center, such as for a bank) identifiesa user and a reason for a call to a recipient device of the user (e.g.,with an inbound phone number). As mentioned above, the reason for thecall may also include an urgency of the call. As also mentioned above,the user and the reason for the call may be identified manually by anagent or automatically based on a pre-programmed algorithm.

In step 2715, informing, by the initiating device, an intermediateservice about the call to the recipient device and the reason for thecall, wherein the intermediate service coordinates with an applicationon the recipient device to inform the recipient device of the call, anoutbound phone number of the call, a name of the organization, and thereason for the call; and

In step 2720, the initiating device may then call the recipient deviceat the inbound phone number (e.g., a voice call or a text message),using the outbound phone number. As detailed above, the application onthe recipient device has configured a caller identification process onthe recipient device to display, in response to receiving the call fromthe outbound phone number, the name of the organization and the reasonfor the call, and does so accordingly.

Note, too that in one embodiment, the application may communicate aresponse to the initiated call to either call again later or toreschedule the call, at which time the initiating device may either callat that later time, or may re-initiate a call (e.g., sending the reasonfor the call again).

The simplified procedure 2700 may then end in step 2725. Other steps mayalso be included generally within procedure 2700. For example, suchsteps (or, more generally, such additions to steps already specificallyillustrated above), may include: selecting the outbound phone numberfrom a plurality of outbound phone numbers is based on availability ofthe outbound phone number and informing the intermediate service of theselected outbound phone number; and so on.

Additionally, FIG. 28 illustrates an example simplified procedurecoordinating conveying a reason for a call to a user device inaccordance with one or more embodiments described herein, particularlyfrom the perspective of an intermediate service. For example, anon-generic, specifically configured device (e.g., device 200,) mayperform procedure 2800 by executing stored instructions (e.g., process248). The procedure 2800 may start at step 2805, and continues to step2810, where, as described in greater detail above, an intermediateservice device receives information about a call to be made from aninitiating device to a recipient device of a user, the informationincluding a reason for the call. In step 2815, the intermediate servicedevice coordinates with an application on the recipient device to informthe recipient device of the call, an outbound phone number of the call,a name of an organization of the initiating device, and the reason forthe call, where the application on the recipient device configures acaller identification process on the recipient device to display, inresponse to receiving a subsequent call from the outbound phone number,the name of the organization and the reason for the call.

In step 2820, the intermediate service device confirms with theinitiating device that the recipient device has been informed of thecall, where in response to the initiating device calling the recipientdevice using the outbound phone number, the caller identificationprocess on the recipient device displays the name of the organizationand the reason for the call.

The simplified procedure 2800 may then end in step 2825. Other steps mayalso be included generally within procedure 2800. For example, suchsteps (or, more generally, such additions to steps already specificallyillustrated above), may include: including the urgency of the callwithin the reason for the call; and so on.

Additionally, FIG. 29 illustrates an example simplified procedure forreceiving a reason for a call at a user device in accordance with one ormore embodiments described herein, particularly from the perspective ofa user device. For example, a non-generic, specifically configureddevice (e.g., device 200) may perform procedure 2900 by executing storedinstructions (e.g., process 248). The procedure 2900 may start at step2905, and continues to step 2910, where, as described in greater detailabove, an application on a recipient device of a user receivesinformation about a call to be made from an initiating device, theinformation having an outbound phone number of the call, a name of anorganization of the initiating device, and a reason for the call. Instep 2915, the application configures a caller identification process onthe recipient device to display, in response to receiving a subsequentcall from the outbound phone number, the name of the organization andthe reason for the call. In step 2920, in response to the initiatingdevice calling the recipient device using the outbound phone number, thecaller identification process on the recipient device displays the nameof the organization and the reason for the call.

The simplified procedure 2900 may then end in step 2925. Other steps mayalso be included generally within procedure 2800. For example, suchsteps (or, more generally, such additions to steps already specificallyillustrated above), may include the reason further including an urgencyof the call. Additional steps may include providing an icon to displayby the caller identification process that indicates the call isvalidated as arriving from the organization, or presenting an option forrescheduling the call for a future time. In other steps, the call mayeither be a voice call or a text message, and so on.

Additionally, FIG. 30 illustrates an example simplified procedure forconveying a reason for a call from a user device in accordance with oneor more embodiments described herein, particularly from the perspectiveof a user device. For example, a non-generic, specifically configureddevice (e.g., device 200) may perform procedure 3000 by executing storedinstructions (e.g., process 248). The procedure 3000 may start at step3005, and continues to step 3010, where, as described in greater detailabove, a user device determines a second device (e.g., a call centerrecipient, such as one of a plurality of devices that could participatein the call) to participate in a call with a user of the user device anda reason for the call. In step 3015, the user device transmits a messageto an intermediate service to inform the intermediate service about thesecond device, the user, and the reason for the call, where theintermediate service conveys the user and the reason for the call to thesecond device. In step 3020, the user device receives the call initiatedby the second device, where the second device is aware of the user andthe reason for the call prior to initiating the call.

The simplified procedure 3000 may then end in step 3025. Other steps mayalso be included generally within procedure 3000. For example, suchsteps (or, more generally, such additions to steps already specificallyillustrated above), may include: conveying an urgency of the call withinthe reason for the call includes an urgency of the call (e.g., selectedby the user based on the reason for the call, etc.); and so on.

Additionally, FIG. 31 illustrates an example simplified procedure forcoordinating conveying a reason for a call from a user device inaccordance with one or more embodiments described herein, particularlyfrom the perspective of an intermediate service. For example, anon-generic, specifically configured device (e.g., device 200) mayperform procedure 3100 by executing stored instructions (e.g., process248). The procedure 3100 may start at step 3105, and continues to step3110, where, as described in greater detail above, an intermediateservice device receives a message from a user device, the messageinformative of a second device to participate in a call with a user ofthe user device and a reason for the call. In step 3115, theintermediate service device conveys the user device, the user, and thereason for the call to the second device, where the second deviceinitiates the call to the user device and is aware of the user and thereason for the call prior to initiating the call.

The simplified procedure 3100 may then end in step 3120. Other steps mayalso be included generally within procedure 3100. For example, suchsteps (or, more generally, such additions to steps already specificallyillustrated above), may include conveying an urgency of the call; and soon.

Lastly, FIG. 32 illustrates an example simplified procedure forreceiving a reason for a call from a user device in accordance with oneor more embodiments described herein, particularly from the perspectiveof call center. For example, a non-generic, specifically configureddevice (e.g., device 200) may perform procedure 3200 by executing storedinstructions (e.g., process 248). The procedure 3200 may start at step3205, and continues to step 3210, where, as described in greater detailabove, a particular device (e.g., a call center device) receives anindication from an intermediate service that a user device requestedthat the particular device participate in a call with a user of the userdevice, the indication also including a reason for the call. In step3215, the particular device determines when the particular device isable to initiate the call. In step 3220, in response to being able toinitiate the call (e.g., determining an available device out of aplurality of devices at the call center), the particular deviceinitiates the call to the user device, where the particular device isaware of the user and the reason for the call prior to initiating thecall.

The simplified procedure 3200 may then end in step 3225. Other steps mayalso be included generally within procedure 3200. For example, suchsteps (or, more generally, such additions to steps already specificallyillustrated above), may include: rescheduling the call, indicating atime of a future call in response the request, and so on.

It should be noted that while certain steps within procedures 2700-3200may be optional as described above, the steps shown in FIGS. 27-32 aremerely examples for illustration, and certain other steps may beincluded or excluded as desired. Further, while a particular order ofthe steps is shown, this ordering is merely illustrative, and anysuitable arrangement of the steps may be utilized without departing fromthe scope of the embodiments herein. Moreover, while procedures2700-3200 are described separately, certain steps from each proceduremay be incorporated into each other procedure, and the procedures arenot meant to be mutually exclusive.

Advantageously, the techniques described herein thus provide forconveying a reason for a call, such as for contact center. Inparticular, the techniques herein provide a frictionless userexperience, making the user's experience as easy and convenient aspossible, where the called party is not only assured that the caller IDis correct, but they are conveyed the reason for the incoming call,including the urgency of the call, and are provided with an easymechanism for rescheduling the call for a different time.

Illustratively, the techniques described herein may be performed byhardware, software, and/or firmware, such as in accordance with aprocess, which may include computer executable instructions executed bya processor (of a particular correspondingly operative computing device)to perform functions relating to the techniques described herein, e.g.,in conjunction with other devices which may have a correspondinglyconfigured processes depending upon the functionality of the device, asdescribed below (e.g., a user device, a storage server, a call centerdevice, a controller device, an attestation service, and so on).

It should also be noted that the steps shown and described in theprocedures above are merely examples for illustration, and certain othersteps may be included or excluded as desired. For instance, other stepsmay also be included generally within procedures above as describedherein. For example, such steps (whether additional steps or furtheranceof steps already specifically illustrated above) may include such thingsas: how communications are managed based on verified/unverifiedidentities, how verification occurs, various timers, procedures forincreased identity verification requests, displayingverification/assurance levels, generating and passing verificationtokens, and so on. Further, while a particular order of the steps isshown, this ordering is merely illustrative, and any suitablearrangement of the steps may be utilized without departing from thescope of the embodiments herein. Moreover, while procedures may bedescribed separately, certain steps from each procedure may beincorporated into each other procedure, and the procedures are not meantto be mutually exclusive.

According to the embodiments herein, an illustrative method herein maycomprise: identifying, by an initiating device of an organization, auser and a reason for a call to a recipient device of the user, the userdevice having an inbound phone number; informing, by the initiatingdevice, an intermediate service about the call to the recipient deviceand the reason for the call, wherein the intermediate servicecoordinates with an application on the recipient device to inform therecipient device of the call, an outbound phone number of the call, aname of the organization, and the reason for the call; and calling, fromthe initiating device and using the outbound phone number, the recipientdevice at the inbound phone number, wherein the application on therecipient device has configured a caller identification process on therecipient device to display, in response to receiving the call from theoutbound phone number, the name of the organization and the reason forthe call.

In one embodiment, the reason for the call includes an urgency of thecall.

In one embodiment, the reason for the call is selected from a groupconsisting of: potentially fraudulent transactions; a change in privacyrules; a special offer; a requested callback; a customer survey; and aresponse to an inquiry.

In one embodiment, the intermediate service coordinates with theapplication on the recipient device by establishing a connectionutilizing an encrypted security token. In one embodiment, the encryptedsecurity token was initially shared between the recipient device and theintermediate service when an account with the organization wasestablished on the recipient device.

In one embodiment, the intermediate service coordinates with theapplication on the recipient device by utilizing a connection, securedby an encrypted security token, where the connection is established andmaintained continuously.

In one embodiment, identifying the user and the reason for call iseither performed manually by an agent or automatically based on apre-programmed algorithm.

In one embodiment, selecting the outbound phone number from a pluralityof outbound phone numbers is based on availability of the outbound phonenumber; wherein the method further comprises: informing the intermediateservice of the selected outbound phone number.

In one embodiment, the call is either a voice call or a text message.

In one embodiment, the application communicates a response to theinitiated call to either call again later or to reschedule the call.

According to the embodiments herein, an illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer, may cause the computer to perform a methodcomprising: identifying, as an initiating device of an organization, auser and a reason for a call to a recipient device of the user, the userdevice having an inbound phone number; informing, an intermediateservice about the call to the recipient device and the reason for thecall, wherein the intermediate service coordinates with an applicationon the recipient device to inform the recipient device of the call, anoutbound phone number of the call, a name of the organization, and thereason for the call; and calling, using the outbound phone number, therecipient device at the inbound phone number, wherein the application onthe recipient device has configured a caller identification process onthe recipient device to display, in response to receiving the call fromthe outbound phone number, the name of the organization and the reasonfor the call.

Further, according to the embodiments herein an illustrative apparatusherein may comprise: one or more network interfaces to communicate witha network; a processor coupled to the network interfaces and configuredto execute one or more processes; and a memory configured to store aprocess that is executable by the processor, the process, when executed,configured to: identify, as an initiating device of an organization, auser and a reason for a call to a recipient device of the user, the userdevice having an inbound phone number; inform an intermediate serviceabout the call to the recipient device and the reason for the call,wherein the intermediate service coordinates with an application on therecipient device to inform the recipient device of the call, an outboundphone number of the call, a name of the organization, and the reason forthe call; and call, using the outbound phone number, the recipientdevice at the inbound phone number, wherein the application on therecipient device has configured a caller identification process on therecipient device to display, in response to receiving the call from theoutbound phone number, the name of the organization and the reason forthe call.

According to the embodiments herein, another illustrative method hereinmay comprise: receiving, at an intermediate service device, informationabout a call to be made from an initiating device to a recipient deviceof a user, the information including a reason for the call;coordinating, by the intermediate service device, with an application onthe recipient device to inform the recipient device of the call, anoutbound phone number of the call, a name of an organization of theinitiating device, and the reason for the call, wherein the applicationon the recipient device configures a caller identification process onthe recipient device to display, in response to receiving a subsequentcall from the outbound phone number, the name of the organization andthe reason for the call; and confirming, by the intermediate servicedevice with the initiating device, that the recipient device has beeninformed of the call, wherein, in response to the initiating devicecalling the recipient device using the outbound phone number, the calleridentification process on the recipient device displays the name of theorganization and the reason for the call.

In one embodiment, the reason for the call includes an urgency of thecall.

In one embodiment, the reason for the call is selected from a groupconsisting of: potentially fraudulent transactions; a change in privacyrules; a special offer; a requested callback; a customer survey; and aresponse to an inquiry.

In one embodiment, the method further comprises: coordinating with theapplication on the recipient device by establishing a connectionutilizing an encrypted security token. In one embodiment, the encryptedsecurity token was initially shared between the recipient device and theintermediate service when an account with the organization wasestablished on the recipient device.

In one embodiment, the method further comprises: coordinating with theapplication on the recipient device by utilizing a connection, securedby an encrypted security token, where the connection is established andmaintained continuously.

In one embodiment, the method further comprises: including, within themessage, the outbound number from which the initiating device is makingthe call, and further wherein the recipient device validates the call byensuring the call is received from the outbound number.

In one embodiment, the initiating device selects the outbound phonenumber from a plurality of outbound phone numbers based on availabilityof the outbound phone number, the method further comprising: receivingthe selected outbound phone number.

In one embodiment, the call is either a voice call or a text message.

In one embodiment, the intermediate service device is associated withthe organization.

In one embodiment, the intermediate service device is associated with athird party service separate from the organization.

In one embodiment, the application is associated with the organization.

In one embodiment, the application is associated with the intermediateservice device.

According to the embodiments herein, another illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer, may cause the computer to perform a methodcomprising: receiving, as an intermediate service, information about acall to be made from an initiating device to a recipient device of auser, the information including a reason for the call; coordinating withan application on the recipient device to inform the recipient device ofthe call, an outbound phone number of the call, a name of anorganization of the initiating device, and the reason for the call,wherein the application on the recipient device configures a calleridentification process on the recipient device to display, in responseto receiving a subsequent call from the outbound phone number, the nameof the organization and the reason for the call; and confirming, withthe initiating device, that the recipient device has been informed ofthe call, wherein, in response to the initiating device calling therecipient device using the outbound phone number, the calleridentification process on the recipient device displays the name of theorganization and the reason for the call.

Further, according to the embodiments herein another illustrativeapparatus herein may comprise: one or more network interfaces tocommunicate with a network; a processor coupled to the networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store an intermediate service process that is executableby the processor, the intermediate service process, when executed,configured to: receive information about a call to be made from aninitiating device to a recipient device of a user, the informationincluding a reason for the call; coordinate with an application on therecipient device to inform the recipient device of the call, an outboundphone number of the call, a name of an organization of the initiatingdevice, and the reason for the call, wherein the application on therecipient device configures a caller identification process on therecipient device to display, in response to receiving a subsequent callfrom the outbound phone number, the name of the organization and thereason for the call; and confirm, with the initiating device, that therecipient device has been informed of the call, wherein, in response tothe initiating device calling the recipient device using the outboundphone number, the caller identification process on the recipient devicedisplays the name of the organization and the reason for the call.

According to the embodiments herein, another illustrative method hereinmay comprise: receiving, at an application on a recipient device of auser, information about a call to be made from an initiating device, theinformation having an outbound phone number of the call, a name of anorganization of the initiating device, and a reason for the call; andconfiguring, by the application, a caller identification process on therecipient device to display, in response to receiving a subsequent callfrom the outbound phone number, the name of the organization and thereason for the call; wherein, in response to the initiating devicecalling the recipient device using the outbound phone number, the calleridentification process on the recipient device displays the name of theorganization and the reason for the call.

In one embodiment, the reason for the call includes an urgency of thecall.

In one embodiment, the reason for the call is selected from a groupconsisting of: potentially fraudulent transactions; a change in privacyrules; a special offer; a requested callback; a customer survey; and aresponse to an inquiry.

In one embodiment, the method further comprises: providing an icon todisplay by the caller identification process that indicates the call isvalidated as arriving from the organization.

In one embodiment, the method further comprises: presenting an optionfor rescheduling the call for a future time.

In one embodiment, the caller identification process compares anincoming phone number to its directory and displays the name of thecaller when the incoming phone number matches a record in the directory.

In one embodiment, the caller identification process compares anincoming phone number to its directory and determines the incoming phonenumber is not in the directory and subsequently queries the applicationfor the identity associated with the incoming phone number.

In one embodiment, the caller identification process queries theapplication for the identity associated with every incoming call.

In one embodiment, the call is either a voice call or a text message.

According to the embodiments herein, another illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer, may cause the computer (an application on arecipient device of a user) to perform a method comprising: receivinginformation about a call to be made from an initiating device, theinformation having an outbound phone number of the call, a name of anorganization of the initiating device, and a reason for the call; andconfiguring a caller identification process on the recipient device todisplay, in response to receiving a subsequent call from the outboundphone number, the name of the organization and the reason for the call;wherein, in response to the initiating device calling the recipientdevice using the outbound phone number, the caller identificationprocess on the recipient device displays the name of the organizationand the reason for the call.

Further, according to the embodiments herein another illustrativeapparatus herein may comprise: one or more network interfaces tocommunicate with a network; a processor coupled to the networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store a caller identification process and an applicationthat is executable by the processor, the application when executedconfigured to: receive information about a call to be made from aninitiating device, the information having an outbound phone number ofthe call, a name of an organization of the initiating device, and areason for the call; and configure the caller identification process todisplay, in response to receiving a subsequent call from the outboundphone number, the name of the organization and the reason for the call;wherein, in response to the initiating device calling the apparatususing the outbound phone number, the caller identification processdisplays the name of the organization and the reason for the call.

According to the embodiments herein, another illustrative method hereinmay comprise: determining, by a user device, a second device toparticipate in a call with a user of the user device and a reason forthe call; transmitting, from the user device, a message to anintermediate service to inform the intermediate service about the seconddevice, the user, and the reason for the call, wherein the intermediateservice conveys the user and the reason for the call to the seconddevice; receiving, at the user device, the call initiated by the seconddevice, wherein the second device is aware of the user and the reasonfor the call prior to initiating the call.

In one embodiment, the second device is a call center further comprisinga plurality of devices that could participate in the call.

In one embodiment, the reason for the call includes an urgency of thecall. In one embodiment, the urgency of the call is selected by theuser. In one embodiment, the urgency of the call is based on the reasonfor the call.

In one embodiment, the reason for the call is selected from a presetmenu.

In one embodiment, the reason for the call is entered by the user.

In one embodiment, wherein the reason for the call is an instruction tothe second device. In one embodiment, the method further comprises:receiving confirmation from the second device that the instruction wasperformed.

In one embodiment, the method further comprises: receiving a requestfrom the intermediate service to validate that the message was initiatedby the user; and responding to the request to validate that the messagewas initiated by the user.

In one embodiment, the method further comprises: completing amulti-factor authentication process to verify the user of the userdevice. In one embodiment, the multi-factor authentication process isperformed during the determining the second device and the reason forthe call.

In one embodiment, the message also informs the phone number of the userdevice.

In one embodiment, determining and transmitting are performed by anapplication on the user device. In one embodiment, the application isassociated with either the intermediate service or the second device.

In one embodiment, the method further comprises: receiving, in responseto second device requiring a delay before the call, a notification of anapproximate wait time for the call prior to receiving the call.

According to the embodiments herein, another illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer (user device), may cause the computer (userdevice) to perform a method comprising: determining a second device toparticipate in a call with a user of the user device and a reason forthe call; transmitting a message to an intermediate service to informthe intermediate service about the second device, the user, and thereason for the call, wherein the intermediate service conveys the userand the reason for the call to the second device; and receiving the callinitiated by the second device, wherein the second device is aware ofthe user and the reason for the call prior to initiating the call.

Further, according to the embodiments herein another illustrativeapparatus herein may comprise: one or more network interfaces tocommunicate with a network; a processor coupled to the networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store a process that is executable by the processor, theprocess, when executed on a user device, configured to: determine asecond device to participate in a call with a user of the user deviceand a reason for the call; transmit a message to an intermediate serviceto inform the intermediate service about the second device, the user,and the reason for the call, wherein the intermediate service conveysthe user and the reason for the call to the second device; receive thecall initiated by the second device, wherein the second device is awareof the user and the reason for the call prior to initiating the call.

According to the embodiments herein, another illustrative method hereinmay comprise: receiving, at an intermediate service device, a messagefrom a user device, the message informative of a second device toparticipate in a call with a user of the user device and a reason forthe call; and conveying, from the intermediate service device, the userdevice, the user, and the reason for the call to the second device,wherein the second device initiates the call to the user device and isaware of the user and the reason for the call prior to initiating thecall.

In one embodiment, the second device is a call center further comprisinga plurality of devices that could participate in the call.

In one embodiment, the message is further informative of an urgency ofthe call.

In one embodiment, the method further comprises: determining an urgencyof the call based on the reason for the call.

In one embodiment, the method further comprises: requesting that theuser device validate that the message was initiated by an authorizeduser; and conveying a result to the second device as to whether themessage was initiated by an authorized user.

In one embodiment, the method further comprises: completing amulti-factor authentication process with the user device to verify theuser of the user device; and conveying a result of the multi-factorauthentication process to the second device. In one embodiment, themulti-factor authentication process is performed prior to receiving themessage.

In one embodiment, the message also informs of a phone number of theuser device.

In one embodiment, the message is received from an application on theuser device. In one embodiment, the application is associated witheither the intermediate service device or the second device.

According to the embodiments herein, another illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer, may cause the computer to perform a methodcomprising: receiving, as an intermediate service, a message from a userdevice, the message informative of a second device to participate in acall with a user of the user device and a reason for the call; andconveying the user device, the user, and the reason for the call to thesecond device, wherein the second device initiates the call to the userdevice and is aware of the user and the reason for the call prior toinitiating the call.

Further, according to the embodiments herein another illustrativeapparatus herein may comprise: one or more network interfaces tocommunicate with a network; a processor coupled to the networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store an intermediate service process that is executableby the processor, the intermediate service process, when executed,configured to: receive a message from a user device, the messageinformative of a second device to participate in a call with a user ofthe user device and a reason for the call; and convey the user device,the user, and the reason for the call to the second device, wherein thesecond device initiates the call to the user device and is aware of theuser and the reason for the call prior to initiating the call.

According to the embodiments herein, another illustrative method hereinmay comprise: receiving, by a particular device, an indication from anintermediate service that a user device requested that the particulardevice participate in a call with a user of the user device, theindication also including a reason for the call; determining, by theparticular device, when the particular device is able to initiate thecall; and initiating, by the particular device and in response to beingable to initiate the call, the call to the user device, wherein theparticular device is aware of the user and the reason for the call priorto initiating the call.

In one embodiment, the particular device is a part of a call center witha plurality of devices that could participate in the call, whereindetermining when to initiate the call is based on determining anavailable device out of the plurality.

In one embodiment, the indication also indicates an urgency of the call.In one embodiment, the urgency is either user selected or determined bythe intermediate service.

In one embodiment, the method further comprises: determining an urgencyof the call based on the reason for the call.

In one embodiment, determining when the particular device is able toinitiate the call based on one or more of the following: i. the reasonfor the call; ii. an urgency of the call; iii. an availability of anagent associated with the particular device; or iv. an availability ofthe particular device from among a plurality of devices of a callcenter.

In one embodiment, the reason for the call is selected from a presetmenu associated with the particular device.

In one embodiment, the reason for the call is entered by the user.

In one embodiment, the reason for the call is an instruction to theparticular device. In one embodiment, the method further comprises:performing the instruction. In one embodiment, the method furthercomprises: instructing a third device to perform the instruction. In oneembodiment, the method further comprises: sending a confirmation to theuser device that the instruction was performed.

In one embodiment, the method further comprises: receiving confirmationfrom the intermediate service that the message was initiated by anauthorized user.

In one embodiment, the method further comprises: receiving confirmationfrom the intermediate service that the user device completed amulti-factor authentication process to verify the user of the userdevice.

In one embodiment, the indication also informs of a phone number of theuser device, initiating the call to the particular device.

In one embodiment, the user device requested that the particular deviceparticipate in the call with the user of the user device via anapplication on the user device. In one embodiment, the application isassociated with either the intermediate service or the particulardevice.

In one embodiment, the method further comprises: determining anapproximate wait time until being able to initiate the call; and sendinga notification to the user device of the approximate wait time prior toinitiating the call.

According to the embodiments herein, another illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer of a particular device, may cause the computerto perform a method comprising: receiving an indication from anintermediate service that a user device requested that the particulardevice participate in a call with a user of the user device, theindication also including a reason for the call; determining when theparticular device is able to initiate the call; and initiating, by theparticular device and in response to being able to initiate the call,the call to the user device, wherein the particular device is aware ofthe user and the reason for the call prior to initiating the call.

Further, according to the embodiments herein another illustrativeapparatus herein may comprise: one or more network interfaces tocommunicate with a network; a processor coupled to the networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store a process that is executable by the processor, theprocess, when executed, configured to: receive an indication from anintermediate service that a user device requested that the processparticipate in a call with a user of the user device, the indicationalso including a reason for the call; determine when the process is ableto initiate the call; and initiate, in response to being able toinitiate the call, the call to the user device, wherein the process isaware of the user and the reason for the call prior to initiating thecall.

While there have been shown and described illustrative embodiments, itis to be understood that various other adaptations and modifications maybe made within the scope of the embodiments herein. For example, thoughthe disclosure was often described with respect to enterprise, or morespecifically, banking, examples, those skilled in the art shouldunderstand that this was done only for illustrative purpose and withoutlimitations, and the techniques herein may be used for any securecommunication environment between any two end-users/systems.Furthermore, while the embodiments may have been demonstrated withrespect to certain communication environments, physical environments, ordevice form factors, other configurations may be conceived by thoseskilled in the art that would remain within the contemplated subjectmatter of the description above. For example, various components andmodules may be distributed in manners not specifically described orillustrated herein, but that provide functionally similar results (e.g.,the timer which was described as part of the AVS Server may in fact beplaced, in one embodiment, in the AVS ACG, and so on). Also, while theterms “inbound” and “outbound” may have been used herein with regard toperspectives from the point of view of a call center/enterprise, thetechniques herein are not so limited, and may generally refer to“inbound” communication as communication received at a receiving device,and “outbound” communication as communication initiated by an initiatingdevice, each regardless of whether the initiating device or thereceiving device is the device that needs to have an associated identityverified by the respective other device.

Additionally, while the description above was provided with respect to aphone call, those skilled in the art should be able to recognize thatthe same process is equally applicable for any other forms ofcommunications, such as, e.g., texting, video calls, etc.

Moreover, while the techniques have been described above in terms ofone-to-one communication, the present disclosure may be applicable toone-to-many or many-to-one communications, such as conference calls, webconferences, and so on. For example, a presenter of a one-to-manyconference with a plurality of end users may wish to convey a reason forthe call/conference. Example scenarios may include board meetings,shareholder meetings, business meetings, school meetings, and so on.

Further, while certain authentication factors and/or verificationresponse inputs have been noted above, other factors/inputs may be usedin accordance with the techniques herein that are not specificallymentioned. Similarly, while certain actions have been listed with regardto managing a communication based on whether the entity to be verifiedis, in fact, verified or unverified, other managing actions may be takenwith the scope of the present disclosure, and those specificallymentioned are non-limiting examples.

The foregoing description has been directed to specific embodiments. Itwill be apparent, however, that other variations and modifications maybe made to the described embodiments, with the attainment of some or allof their advantages. For instance, it is expressly contemplated thatcertain components and/or elements described herein can be implementedas software being stored on a tangible (non-transitory)computer-readable medium (e.g., disks/CDs/RAM/EEPROM/etc.) havingprogram instructions executing on a computer, hardware, firmware, or acombination thereof. Accordingly this description is to be taken only byway of example and not to otherwise limit the scope of the embodimentsherein. Therefore, it is the object of the appended claims to cover allsuch variations and modifications as come within the true intent andscope of the embodiments herein.

What is claimed is:
 1. A method, comprising: determining, by a userdevice, a second device to participate in a call with a user of the userdevice and a reason for the call; transmitting, from the user device, amessage to an intermediate service to inform the intermediate serviceabout the second device, the user, and the reason for the call, whereinthe intermediate service conveys the user and the reason for the call tothe second device; and receiving, at the user device, the call initiatedby the second device, wherein the second device is aware of the user andthe reason for the call prior to initiating the call.
 2. The method ofclaim 1, wherein the second device is a call center further comprising aplurality of devices that could participate in the call.
 3. The methodof claim 1, wherein the reason for the call includes an urgency of thecall.
 4. The method of claim 3, wherein the urgency of the call isselected by the user.
 5. The method of claim 3, wherein the urgency ofthe call is based on the reason for the call.
 6. The method of claim 1,wherein the reason for the call is selected from a preset menu.
 7. Themethod of claim 1, wherein the reason for the call is entered by theuser.
 8. The method of claim 1, wherein the reason for the call is aninstruction to the second device.
 9. The method of claim 8, furthercomprising: receiving confirmation from the second device that theinstruction was performed.
 10. The method of claim 1, furthercomprising: receiving a request from the intermediate service tovalidate that the message was initiated by the user; and responding tothe request to validate that the message was initiated by the user. 11.The method of claim 1, further comprising: completing a multi-factorauthentication process to verify the user of the user device.
 12. Themethod of claim 11, wherein the multi-factor authentication process isperformed during determining the second device and the reason for thecall.
 13. The method of claim 1, wherein the message also informs of aphone number of the user device.
 14. The method of claim 1, whereindetermining and transmitting are performed by an application on the userdevice.
 15. The method of claim 14, wherein the application isassociated with either the intermediate service or the second device.16. The method of claim 1, further comprising: receiving, in response tosecond device requiring a delay before the call, a notification of anapproximate wait time for the call prior to receiving the call.
 17. Atangible, non-transitory, computer-readable medium havingcomputer-executable instructions stored thereon that, when executed by aprocessor on a computer of a user device, cause the computer to performa process comprising: determining a second device to participate in acall with a user of the user device and a reason for the call;transmitting a message to an intermediate service to inform theintermediate service about the second device, the user, and the reasonfor the call, wherein the intermediate service conveys the user and thereason for the call to the second device; and receiving the callinitiated by the second device, wherein the second device is aware ofthe user and the reason for the call prior to initiating the call. 18.The tangible, non-transitory, computer-readable medium of claim 17,wherein the reason for the call includes an urgency of the call.
 19. Thetangible, non-transitory, computer-readable medium of claim 17, theprocess further comprising: receiving a request from the intermediateservice to validate that the message was initiated by the user; andresponding to the request to validate that the message was initiated bythe user.
 20. An apparatus, comprising: one or more network interfaces;a processor coupled to the one or more network interfaces and configuredto execute one or more processes; and a memory configured to store aprocess that is executable by the processor, the process when executedon a user device, configured to: determine a second device toparticipate in a call with a user of the user device and a reason forthe call; transmit a message to an intermediate service to inform theintermediate service about the second device, the user, and the reasonfor the call, wherein the intermediate service conveys the user and thereason for the call to the second device; and receive the call initiatedby the second device, wherein the second device is aware of the user andthe reason for the call prior to initiating the call.